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