Thanks for your reply.
At 11:18 03/06/25 +0200, you wrote:
>At 21:22 03/06/24 +0000, you wrote: >>This one time, at band camp, tek1 said: >> >>t>I'm using CastorJDO with my J2EE application to obtain the JDO reference >>t>from JNDI. Everything is working fine, except for the transaction >>t>management. When an exception occurs, the operations performed by Castor >>t>are not rolled back, even though the below is specified in the CastorJDO >>MBean: >>t> >>t>_jdo.setTransactionManager("java:/TransactionManager"); >> >>This is perplexing because the DatabaseImpl.rollback() method calls >>TransactionContext.rollback() which should rollback anything in Castor's >>transactional context. What types of results are you seeing? Please >>explain what's happening and we'll see if we can work through it or I'll >>build a simple test case for it. >> >>Bruce > > >Hi Bruce. > >Thanks for your reply. > >Basically, I have a Stateless Session Bean ("A") with methods a() and b(): > > >A >=== >public void a() <-- called by web client >protected void b(Database db) > > >1. a() obtains the JDO instance from JNDI, and from the JDO instance, >obtains a Database instance. >2. In performing the business logic, a() makes a call to b(), in which a() >passes the Database instance to b(). >3. b() performs does a db.load(class,id) on an object, and changes the >value of one of the object's attributes using setXXX(). >4. b() returns a value (that it computed) to a(). >5. At some point in the remainder of a()'s execution, an exception occurs.
What are you doig with this exception ? If you are planning to use container-managed transactions (and that's how I
understand your use case), make sure that the right kind of exception is propagated up the exceution chain. If you
simply catch your application exception, log an error but prevent the exception from bubbling up, how should the
container know that it should rollback your transaction ? I migth be completely wrong with this question, but it seems
worth asking at least.
Any exception that occurs in b() is caught and rethrown as an EJBException so that a(), the caller of b(), can handle it. Again though, b() executes fine, but an exception occurs in a(), after the call to b(), and the operations performed by Castor in b() are not rolled back.
>6. The changes made to the object in b() are not being rolledback. When I
>check the database, the value has been changed/committed, when it should
>not have been... :(
>
>Thinking that the cause may have been because I did not set a()'s
>transaction attributes in ejb-jar.xml, I then added the "Required"
>transaction attribute for a().
Looking at this, I was just about to ask whether you specified in the deployment descriptor of your web app that
(global) transactions are required when invoking methods of your EJBs. Having said that, it might be worth to specify
such attribute for b() as well. Please make sure that you use a different transaction type (whose name I simply cannot
remember right now), i.e. one where an existing transaction is usef if available, otherwise a new one will be started.
a() is correctly defined as having the transaction attribute type, "Required". ("Required" continues in an existing transaction, but if an existing one does not exist, a new one is created.) Regarding b(), it is not an EJB interface method (i.e. it is not called by an EJB client; it is simply an internal method used by a()), so it does not require EJB transaction settings.
Thanks for your feedback though.
Are you currently using Castor in a J2EE environment?
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
