RE: Transaction behaviour
Title: RE: Transaction behaviour Orion's implementation is quite correct in returning a method result and not throwing any exceptions, in spite of your invocation of setRollbackOnly. Personally, I only call setRollBackOnly before (re-)throwing an application exception that should definitely cause a rollback. Rolling back the transaction without throwing any exceptions will just confuse the users of my ejb's. It is probably better to just wrap such an application exception in an EJBException and let the container roll the tx back. Remember that CreateException, RemoveException and FinderException are considered to be application exceptions. If you propagate these exceptions but still want to roll the tx back, you have to catch them, call setRollbackOnly() and then rethrow them. Subclasses of Error, RuntimeException (EJBException) and RemoteException are considered to be system exceptions and will automatically cause a tx rollback. -Original Message- From: Justin Crosbie [mailto:[EMAIL PROTECTED]] Sent: 19 October 2001 05:34 To: Orion-Interest Subject: Transaction behaviour Hi all, We have implemented a session facade architecture, with session beans calling multiple entity beans. We have configured the trans-attribute as Required for everything, as normal. What is the exact criteria for a session method to rollback? Is it that it must be a system initiated exception, or else the application must call setRollBackOnly()? Its just that calling this method causes a rollback, but the the container does not come up with the Session was rolled back exception, so I'm a bit worried about it. I know this has been addressed before on this list, so I apologise for going over old stuff, but I've noticed that some applications call the setRollbackOnly method and others don't. Is it just that those ones don't care if a rollback occurs? Specificaly, we have a stateless session bean that we invoke through a statefull one (that a servlet creates and invokes). The stateless bean always tries to create the entity beans. We would like it such that if either fails to create, the method does a rollback - all or nothing. Does this mean that we must call setRollbackOnly() ? Thanks for any help on this. Justin
CMT and datasources
Title: CMT and datasources Hi all How can I get an Oracle XA-datasource to work in Orion in such a way that it leverages Orion transaction management (CMT)? Here is my attempted datasources.xml. data-source class=oracle.jdbc.xa.client.OracleXADataSource name=DB location=jdbc/DBXASource url=jdbc:oracle:oci8:vc/vc@ORACLE inactivity-timeout=30 schema=database-schemas/oracle.xml / data-source class=com.evermind.sql.OrionCMTDataSource name=DBXA location=jdbc/DBXA xa-source-location=jdbc/DBXASource inactivity-timeout=30 schema=database-schemas/oracle.xml / I use an O-R mapping tool, which assumes a JTS CMT DataSource at the JNDI location jdbc/DBXA. When I throw an EJBException, which according to spec should cause a transaction rollback, the SQL issued through the connection still seems to be committed.
RE: Transaction management in BMP through Session bean
Your JDBC drivers have to be JTA/JTS enabled. JTA enabled drivers would have some implementation of the javax.transaction.Synchronization interface which would somehow be registered with Orion's implementation javax.transaction.TransactionManager. Exactly how this works is container and driver specific. With Websphere, for instance, jdbc connections are only JTA enabled if you use DB2's jta jdbc drivers. With WebLogic, you have to use BEA's JDrivers and connection pools. Assume therefor by default that your jdbc driver and Orion do not share the same transaction context. The behaviour you have described kind of points to that direction. By the way, does anyone know how I could get a reference (pointer) to Orion's implementation of javax.transaction.TransactionManager? I need this to link Toplink's JTA enabler to Orion. Also, since Oracle and Orion are such good buddies nowadays, does anyone know if and when there would be Oracle jdbc drivers that would be JTA enabled in Orion? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 06 July 2001 11:50 To: Orion-Interest Subject: Transaction management in BMP through Session bean In a BMP, if we throw an EJBException all the changes would be rolled back by the container, right? Or do we have to write code to do that? I was reading through your reply in the list and I have a doubt regarding something regarding transaction handling in BMP entity beans. I am using the entity bean in a session bean and have two sql statements and one entity update. If one of the sql statements fails and the entity is updated , the changes are all rolled back, but in the case of the entity failure to update, the sql statement changes are not rolled back and I get an error saying System/communication error: Transaction was rolled back: Error preparing bean in stance: com.evermind.transaction.MarshallingXAException; nested exception is: com.evermind.transaction.MarshallingXAException The entity bean is throwing an EJBException back to the Session bean, but the session bean does not catch it and continues forward as if nothing happened. The funny thing is that the queries are placed like this sqlinsert 1... entitybean update sqlinsert 2. So the flow becomes sqlinsert 1 happens then sqlinsert 2 and only in the end does the entity bean throw the exception any idea why this happens? Can anyone help me on this. The BMP entity has persistence persistence-typeBean/persistence-type Thanks Kind Regards Aby application/ms-tnef
RE: Transaction management in BMP through Session bean
Although, after doing some reading, it seems like the class: com.evermind.sql.DriverManagerXADataSource does indeed provide you with shared distributed transaction context. Have you tried looking up your DataSource from the xa-location as specified in your data-sources.xml? -Original Message- From: Ampie Barnard Sent: 06 July 2001 02:19 To: 'Orion-Interest' Subject: RE: Transaction management in BMP through Session bean Your JDBC drivers have to be JTA/JTS enabled. JTA enabled drivers would have some implementation of the javax.transaction.Synchronization interface which would somehow be registered with Orion's implementation javax.transaction.TransactionManager. Exactly how this works is container and driver specific. With Websphere, for instance, jdbc connections are only JTA enabled if you use DB2's jta jdbc drivers. With WebLogic, you have to use BEA's JDrivers and connection pools. Assume therefor by default that your jdbc driver and Orion do not share the same transaction context. The behaviour you have described kind of points to that direction. By the way, does anyone know how I could get a reference (pointer) to Orion's implementation of javax.transaction.TransactionManager? I need this to link Toplink's JTA enabler to Orion. Also, since Oracle and Orion are such good buddies nowadays, does anyone know if and when there would be Oracle jdbc drivers that would be JTA enabled in Orion? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 06 July 2001 11:50 To: Orion-Interest Subject: Transaction management in BMP through Session bean In a BMP, if we throw an EJBException all the changes would be rolled back by the container, right? Or do we have to write code to do that? I was reading through your reply in the list and I have a doubt regarding something regarding transaction handling in BMP entity beans. I am using the entity bean in a session bean and have two sql statements and one entity update. If one of the sql statements fails and the entity is updated , the changes are all rolled back, but in the case of the entity failure to update, the sql statement changes are not rolled back and I get an error saying System/communication error: Transaction was rolled back: Error preparing bean in stance: com.evermind.transaction.MarshallingXAException; nested exception is: com.evermind.transaction.MarshallingXAException The entity bean is throwing an EJBException back to the Session bean, but the session bean does not catch it and continues forward as if nothing happened. The funny thing is that the queries are placed like this sqlinsert 1... entitybean update sqlinsert 2. So the flow becomes sqlinsert 1 happens then sqlinsert 2 and only in the end does the entity bean throw the exception any idea why this happens? Can anyone help me on this. The BMP entity has persistence persistence-typeBean/persistence-type Thanks Kind Regards Aby application/ms-tnef
