Problem: We have several general purpose classes we wish to implement as Stateless Session EJB's. These classes participate in different operations like query/add/update/delete. For each operation we want to specify different isolation levels: query=TX_READ_UNCOMMITTED, add/update/delete=TX_SERIALIZABLE. When we attempt to do this on IBM WebSphere 3.02 we run into the following problem: whatever isolation level was set on the first method invocation of the Trx, the same isolation must be specified on every other method invocation involved in the transaction, whether they are on the same EJB or other EJB's. This seems to include standard EJB API methods like create() and findByPrimaryKey(). Well, if methods like create() and findByPrimaryKey() fall under the same restriction we are essentially restricted to 1 isolation level for that entire EJB. If we want to support different isolation levels for the same functionality we have to write a new EJB for each isolation level. It seems that the concept of code reuse is in direct conflict with current support for EJB Transactions. The EJB 1.0 Spec appears to reinforce (explain) the behavior described above. The EJB 1.1 Spec appears to back away from transaction isolation, addressing issues like above in extremely vague terms. Solutions(?): We can simply not use EJB's when generic classes need to participate in different types of transactions. This is not what we want to do but it works. What I would like to see is a standard for container providers that solves this problem in the following way: when a new transaction starts the container is aware of the specified isolation level and automatically applies that same isolation level to all remaining method invocations in that transaction. I have no idea how difficult this might be for container providers to implement but it would be nice for bean providers in the above scenario. Future Direction?: Does anyone have insight into how this particular problem might be addressed in the 2.0 Spec? =========================================================================== 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".
