>1) EJB's are TRANSACTIONAL components (MTS components are also
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
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
>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
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
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -