Well, after giving it much thought, I figured ( I hope correctly ), that the very nature of XA pools is transactional in nature. So, it didn't make sense for me to have an entity bean using a connection from an XA connection pool that didn't want to take part in a transaction. Therefore, I changed the entity bean's transaction to REQUIRED, and everything seems to be hunky dory now. I suspect that there is a pool available for non-transactional database connections, but I have not had the time ( translate into lazy :) to figure it out. Thanks for the reply! Wes -----Original Message----- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 29, 2000 9:24 AM To: 'jBoss' Subject: RE: [jBoss-User] Minerva Data Pool Resource Rolling Back Transact ion I can only address the question about turning off auto commit. The container/TransactionManager needs to control the commit and rollback of transactions otherwise you can have a transaction from the container (and client's) point of view executed non-atomically, meaning part happens and part doesn't. An example would be a transfer of funds from savings to checking. If autocommit is on I can easily take the money out of the savings account but fail to add it into the checking account, or vice versa depending on the order of operations. With autocommit off the container will only commit the change if both updates are successful. Cheers Jay Walters -----Original Message----- From: Wes Mckean [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 5:08 PM To: jBoss (E-mail) Subject: [jBoss-User] Minerva Data Pool Resource Rolling Back Transaction I have a connection pool setup using the iNet driver. I can see that when the connection pool is started, a BEGIN TRANSACTION is issued on the connection in MS SQL Server. After every SQL statement executed (viewed using trace), I see the SQL statement IF @@TRANCOUNT > 1 ROLLBACK TRAN BEGIN TRAN This is causing any updates I do to be rolled back. My test entity bean is setup to not use transactions. I believe this is happening because the data pool sets auto commit to false when it creates the connection. This doesn't make sense to me, since the connection will remain around in the pool for a long time, and it is unlikely that the bean will or anything else for that matter will do a RANDOM COMMIT TRANS to cause everything done on that connection to flush. So, any updates, inserts, or deletes done on this connection will not be committed, ever. Is this an error on the part of the TDS driver? Or is it an error of Minerva? Why does Minerva need to set auto commit off, if transaction management will handle this? Wes -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED]
