CMP EEJB update behaviour

[florinduroiu]

Hi all,
I'm having a problem with Jboss 2.4.0 (yes, it's old, I know but I have inherited this deployment) and a CMP entity bean and an Oracle 8 DB as storage. Anyway, I think my problem also connects with 3.0 as the involved jboss files from the JAWS engine that I have checked look the same as the ones in 2.4.0.

I'm using a simple setter and marked the method with "Required" transaction attribute. When I use the setter to set the corresponding field value, no exception is being thrown and the bean updates correctly (I'm checking the field with the corresponding get method). The probelm came when checking the database where no update took place. First I have suspected the mechanism of synchronizing the bean state into the database but it wasn't that. On a thorough look with the p6spy as well as using a Jboss debugging session, I have ended up in the org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand class at the method:
protected Object jdbcExecute(Object argOrArgs) throws Exception
When checking the autoCommit flag of the Connection object, I have learned that it was false (the connection is being aquired using the JNDI lookup of the already set-up DataSource in jboss.jcml).
This means that after the (succesful) execution of the update, when the finally block closes the connection object, the SQL statement is being rolled back. Nevertheless, the method returns with no exception and from the container as well as client view, everything seems allright by only the bean object is being updated with the new value, not its persistent fields.
Also the SQL select statements (used ultimately by jboss persistence engine to obtain the values for the bean fields) ar reported as rolled back by p6spy tool for the same reason (autocommit set to false).
I was quite puzzeled by this behaviour as some other beans in the application are behaving OK with no reports of rollbacks. Still a number of other beans are exhausting the behaviour that I've just explained.
As a potential clue, we are using isModified flag to hint the container about the updates (set to true at setters and false at ejbStore) but I don't believe that this is the problem.
I have also checked the 3.0 corresponding source files and I noticed that JDBCCommand and JDBCUpdateCommand (the classes involved in this logic) are looking the same as the ones in the 2.4.0 release. Here are some convenience links to them (just found them over the net):
http://www.thecortex.net/clover/eg/jboss/report/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.html

http://www.thecortex.net/clover/eg/jboss/report/org/jboss/ejb/plugins/jaws/jdbc/JDBCUpdateCommand.html

If you check JDBCCommand.java at line 175, there is a call to
executeStatementAndHandleResult(stmt, argOrArgs);
I could not find an explicit commit action in the executeStatementAndHandleResult in JDBCUpdateCommand and this means that in JDBCCommand at line 195 where the connection is being closed, the whole transaction will rollback because the autocommit is set to false.

I don't believe this is a bug in jboss whatsoever, but I just can't figure out what I may do wrong.

If you have any idea about this issue, please respond. I'll be very happy.

thx
florin

[florinduroiu]

Well, I got the answer myself. The transaction attribute for the setter method was set to "Supports" by mistake and there was no transaction started before. This means that the setter will execute with no transaction context.
While no exception is being thrown (it shouldn't be actually) the transaction is not commited to the store and is being silently rolled back by the database (no exception is forwarded) while the new value of the field is saved into the bean instance.
I really don't know what's the correct behaviour since the bean instance holds a new value which will be not commited to the store. Maybe the container should at least warn (at deployment time) the bean developer about the potentially non-transactional update to the database.

florin