Thanks, but we actually do call rollback when hitting the timeout exception, which anyway fails because the container has already rolled back the transaction.

Again, what I am seeing is that for a (supposedly) unique transaction, everything that was perform before timeout time is rolled back, the rest gets committed.

Also note that if I comment out the CPU intensive computations running between each entity bean creation, I see a normal behavior, i.e everything gets rolled back if there is a timeout. I suspect the container has a bug where after some time of non transactional resource activity from the thread, he loses knowledge of the fact that the server thread runs in a timed out transactional context.

alex.

May Charles N wrote:
This may be obvious to you, but it wasn't to me until I was faced with it: unless the database rolls its transaction back for you, realize that you have to roll back your session transaction explicitly. In your Session Bean method I would include something like:
 
try {
    //...do your stuff
}
catch (Exception ex) {
    getSessionContext().setRollbackOnly();
    throw ex;
}
 
-----Original Message-----
From: Alex Vauthey [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 9:53 PM
Subject: EJB Transaction Integrity Issue

Hi,

I'm experiencing a serious issue with Weblogic and I was curious about what should be the expected behaviou of any EJB container with the following scenario:

- Start a User transaction in a client JVM with transaction timeout set to 2 seconds
  - Call a session bean within this transaction (Transaction attribute set to REQUIRED)
    - Within the session bean, create 20 entity beans in a loop (Transaction attribute of
      entity beans is REQUIRED), doing some CPU intensive tasks between each creation
      (approx 1 second between each bean creation).
- commit User Transaction on the client

I'm using one transactional datasource for all db accesses.

What I'm experiencing is the following :

I get a timeout exception when I try to commit (sounds normal), but I end-up with 18 entity beans committed in my db !! It seems like anything that happened in the session bean after the timeout was comitted. My guess is that, at timeout time, the container dissociates the thread from the transaction context, but the thread keeps running. Therefore each subsequent entity bean creation happens in its own transaction, since the entity bean attribute is marked as REQUIRED.

Any clarification with regards to what **Should** happen in this scenario would be appreciated.


Rgrds, alex.

--

Alexandre Vauthey
Server Technology Mgr.

Application Networks
444 Ramona Street
Palo Alto, CA 94301

<!--[if !supportEmptyParas]--><!--[endif]-->Tel: 1 (650) 462 7224
Fax: 
1 (650) 462 7221

<!--[if !supportEmptyParas]--><!--[endif]-->

www.application-networks.com





***************************************************************** DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator.


--
AppnetSign

Alexandre Vauthey
Server Technology Mgr.

Application Networks
444 Ramona Street
Palo Alto, CA 94301

Tel: 1 (650) 462 7224
Fax: 
1 (650) 462 7221

www.application-networks.com






=========================================================================== 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".

Reply via email to