(New to EJB, evaluating EJB perf, scalability issues, design options) I'm a little confused with commit options: A - maintain exclusive ready instance between transactions, B - maintain instance between transactions but re-read on transaction begin, C - do not maintain ready instance between transactions. Am I correct in assuming:

a) that "A" retains BOTH the Java Entity Bean instance and the lock on the database object between transactions, so that it doesnt have to reread the database object for the next transaction?
b) that "B" retains only the Java Entity Bean instance, but not the lock on the database object, between transactions. So it has to reread the database object when the next transaction begins
c) that "C" throws away the Java Entity Bean instance itself when the transaction ends.

If so:
1) Say an entity bean instance(to which we are holding a local interface) has an accessor method with the "Supports" transaction attribute. This accessor method is run WITHOUT a surrounding transaction (that's possible, correct?). I assume that for Option "A" the data is returned without a corresponding database read - the cached existing instance is used. Even in Option "B", since there is no transaction, does it mean that cached data will be returned? And for Option "C", what happens? I assume that since this IS Option "C", even though we are holding on to a local interface, the object will be retrieved from database only when the accessor method is called, and then thrown away. Are these correct assumptions?
2) Same thing as above, but this time, we run the accessor method INSIDE a transaction. What happens? Specifically for Option B? And for Option C - will it continue to keep holding on to the Entity Bean instance until the transaction ends?
3) Yet another scenario - Say there are multiple containers - all running commit Option A, pointing to the same DB. So even a simple load of the same Entity Bean instance simultaneously by all containers should fail in all but the first container, correct? Because only the first would capture exclusive access? However, for "B" and "C", the load should succeed (no exclusivity requirement), but later simultaneous access by multiple containers in multiple transactions (one per container) should fail in all but one, because during a transaction I believe exclusive access must be maintained through locking?

Hope the drift of all these questions is very clear. Complete answers or pointers to specific documentation would be much appreciated. Pointing out of vendor specific variations in this regard only would be highly appreciated (you are saving me tons of work). FYI, I've already pored through Mastering EJB 2nd Edition by Ed Roman et al and not completely through the monster EJB 2.0 spec.

Sundeep

Sundeep,

Borland Enterprise Server supports all the commit options as defined in the specification. I have a paper that enumerates the behavior of entity beans running under the auspices of our AppServer when using different transaction commit options.

I could send you this paper. Just drop me a mail krish at borland dot com if you're interested. The paper is focussed on Borland's EJB Container (though different vendors have different ways of doing things).

-krish

http://bdn.borland.com/article/images/29074/transaction_commit_options.pdf