[UPHPU] Java and Frameworks (was: MVC) - Slight Change

John lists at strictlyrockymountain.com
Thu Nov 11 22:35:18 MST 2004


Opps, I should have said "watch what the result is of one process/function
before"...

--
Thanks
John

> Thanks for the explanation, I wasn't aware of nor have I heard the term
> "one atomic unit".  From experience also I have made systems that
> certainly watch what the result is of one transaction before processing
> the next, but I realize what your saying, that my second process most
> certainly cannot stop the first process if the second cannot proceed.
> And that is what a transaction and roleback, etc. is all about.  Thanks
> again.
>
> --
> Thanks
> John
>
>> Your code is not a transaction. Notice that I said "all as one atomic
>> unit" below. This means that if any one (or more) of the actions
>> fails, then they all must fail. You wouldn't want a customer's credit
>> card to be charged, while the inventory system was unable to update
>> the
>> inventory. The classic example is moving money from one bank account
>> to another. This consists of two actions:
>>
>>   1. Debit the money from one account
>>   2. Credit the money to the other account
>>
>> If action 1 fails, but action 2 succeeds, the bank is not going to be
>> happy (good news for you though). A transaction system forces either
>> all or neither of the actions to happen, and will guarantee this for
>> you. Thus, the actions happen as one atomic unit, a transaction. PHP
>> does not have this. J2EE does. By the way, not many frameworks provide
>> transaction support, so I don't really consider this a strike against
>> PHP, but more like a plus for J2EE vs. all others.
>>
>> By the way, this is very difficult to accomplish manually. As the
>> number of actions in your transaction increases, the complexity of a
>> manual solution increases exponentially. I know, because I've written
>> one before. It only had two actions, but it was hard enough that it
>> taught me the value of a framework-managed transaction system (like
>> container managed transactions in J2EE). I would certainly not like to
>> implement a transaction manually with 5 actions!
>>
>> Here's some more info (just a Google search) if you're still curious:
>> http://tinyurl.com/5ykbl
>>
>> --Dave
>>
>> <quote who="John">
>>> Dave, can you explain to me what transactions are.  I know what they
>>> are in MySQL/Postgresql, but from your explanation below I have done
>>> what I think your saying.  I have written a function that charges a
>>> credit card, update the master transaction table and sends an email.
>>> I've even go farther into making each their own function.
>>>
>>> I want to say that I completely understand the re-usability of code
>>> stored in memory as an object, and PHP doesn't do that.  However that
>>> would be awesome and make PHP OO programming much much more, IMHO.
>>>
>>> --
>>> Thanks
>>> John
>>>
>>>> <quote who="John David Anderson">
>>>>> From all I can tell (and I'm no big PHP or Java guru), but PHP is
>>>>> just as good as Java. I personally like PHP because its more
>>>>> flexible and way less verbose.
>>>>> System.out.println.righthere.astext.please("hello") vs. echo "Hi."
>>>>> :o)
>>>>
>>>> PHP and Java Servlets are fundamentally different from eachother by
>>>> design. There is one big factor: persistent objects. In a Servlet,
>>>> when you create an instance of a class, it can remain in memory to
>>>> be reused by subsequent HTTP requests. In PHP, such instances must
>>>> be serialized and persisted to a session (typically written to a
>>>> file, relational DB, or a ramdisk). This design makes Servlets able
>>>> to handle *huge* volumes of users concurrently because objects don't
>>>> have to be deserialized and re-created to be reused. They just
>>>> "stick around" in memory. This is why Java excels in the enterprise
>>>> web arena. That, and it has a huge marketing department and much
>>>> more "official" support.
>>>>
>>>> Not to mention, when you talk about Enterprise Java (J2EE), you
>>>> aren't just talking about web applications and JSP, you're also
>>>> taking about transaction support. And PHP certainly does not have
>>>> that. How can you write a PHP transaction that credits a credit
>>>> card, modifies an inventory record, updates an internal accounting
>>>> system, and emails notification, all as one atomic unit. That is not
>>>> easy in PHP. It's not easy in Java either, but it's at least
>>>> supported.
>>>>
>>>> --Dave
>>
>>
>> _______________________________________________
>>
>> UPHPU mailing list
>> UPHPU at uphpu.org
>> http://uphpu.org/mailman/listinfo/uphpu
>> IRC: #uphpu on irc.freenode.net
>>
>> Sponsored by hostinginferno.com!
>
>
>
>
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>
> Sponsored by hostinginferno.com!






More information about the UPHPU mailing list