[Zope] Python and EJB (J2EE)

[Hung Jung Lu]

>1) EJB's are TRANSACTIONAL components (MTS components are also
>transactional)

Thanks for your comments. Transaction certainly is one of the important 
features of EJB. But my personal opinion is that instance pooling 
(multi-threading) is even more important. If you have to implement a 
components server from scratch, and you can only do so much, which feature 
would you implement first? Transaction? Or Multithreading? I think the 
answer is Multithreading.

>All this can be specified in a deployment-descriptor - an XML
>"properties" file.

Yeap. :) XML "properties" file is the way to go. For many things.

>    Thus multiple database servers at different sites on the net can
>participate in a single transaction.  This implicitly involves TWO-PHASE
>COMMIT and XA/TX interfaces. In plain words, if one database engine in a
>distributed transaction decides to rollback, all other engines must
>rollback as well.

Two-phase commit is crucial. That's why I explicity mentioned it in my 
original message: the final commit must be done in matter of milliseconds, 
if not microseconds. Let's face it, the commit action takes time. There is 
never a 100% sure trasaction. NEVER EVER, since the transaction can fail 
exactly when you are performing the commit action. So the next best thing to 
do is to commit in two phases: (1)prepare to commit: which can take a few 
seconds to prepare everything up to the point of hanging all the transaction 
changes on one single index field (a few bytes), (2) Final commit: modify 
those few bytes, which on a single machine means of the order of 
nano-seconds, and on distributed transaction, microseconds to milliseconds. 
Milliseconds certainly is still not very comforting, but it beats a commit 
action that takes 30 or 40 seconds that is totally unacceptable in business.

>Hence EJB's can potentially participate in DISTRIBUTED TRANSACTIONS.

Yes, totally agree with you.

>4) ENTITY EJB's allow programmatic access to database rows

That's the object mapper. I am not sure, though, whether it's the best 
approach to put the object mapper as part of the Components Server. The fact 
that even SUN's own people recommend against using entity beans tells me a 
lot. Object mapper can be used as an independent utility, outside the 
Components Server.

>We need more of these for transactional components. However I think
>before that Zope will need to evolve to include the next level of
>sophistication in DB transaction
>management, especially two-phase commit, XA/TX ..., support for existing
>transaction co-ordinators, and/or provide one.

I've mentioned two-phase commit to Digicool people. Not sure whether it's 
already inside Zope or not, but it seems not. Zope's TM (Transaction 
Machinery) does not seem to be two-phase. See the TM.py file itself: it only 
has

    def _finish(self):
        self.db.commit()

That is, I don't see the equivalent of prepare_to_commit().

If you know where to get more info on XA/TX, could you provide some 
pointers?

thanks,

Hung Jung

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com