> > Which, if any, of the above methods is recommended. If options 2 or 3 > are used, will this work correctly with transactions? Will the cached > object “enter” an existing transaction when it is first referenced from > such a transaction. >
It depends on the stub you're getting, and how the container enrolls EJBs with a transaction (and specially how it "de" rolls them). I've done this with Orion 1.4.7 - 1.6.0 and it works perfectly. A properly written container shouldn't have problems, but these could be present in "buggy" containers: Heuristic Deadlock: EJBs aren't disengaged from a tx when it finishes, thus they're locked by a transaction and aren't handed over to another transaction. This results in Deadlocks which are "solved" by terminating said tx's (the container should handle this for you). Stale data: This has to do with cache options and the stub itself. It's likely that you could have problems with this unless you fine tune deployment settings. Summarizing, you're going to have to try and play with deployment settings for this to work exactly as you expect it, but I think it's achievable (and desirable) in most EJB servers. My 2c, JP -- ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
