[UPHPU] Java and Frameworks (was: MVC)

David Smith DavidSmith at byu.net
Thu Nov 11 20:36:16 MST 2004


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



More information about the UPHPU mailing list