I'm seeing the exact same problem. I've seen several messages on here related to this problem, but no solutions?
So this is just a message to start the thread back up.
I'm calling a stateless session bean from a client. That session bean calls a CMP bean to make a database change.
When running outside of a transaction this works fine. When running inside a UserTransaction created in the client, the CMP changes are not written to the database, but are refelcted in the bean. It's like the commit is making into jboss, but not into the database.
If I edit the client code and remove the transaction calls, changes to the CMP are updated in the database.
Any ideas? This is JBoss 2.4.4, with Oracle 8i using the thin jdbc drivers (I've tried classes111.zip and classes12.zip and have same results).
I, too, have such a problem. I'm using JBoss 2.4.3 with MySQL (for development). Using MySQL-Max, with INNODB table types and the MM (v2.0.6) JDBC driver, I've demonstrated that transactions work. And with an EJB client UserTransaction I've shown that rollback works on JBoss. But when I commit() a UserTransaction, though the method returns normally, the transacted data are not visible in the DB, and the entities involved remained locked to other transactions.
Effectively for me, JBoss does not support transactions. I'd like to hear about anyone else who has them working, the configuration used, and a sample client program that uses them.
You don't show your code, I can't judge if this might be the problem. In jboss at the moment you have to get a connection after the transaction starts and close it before it ends. Also (as a consequence) don't hold connections across method invocations.
The same happens if you run from a client
o = home.create("1");
The first time it runs, second time crashes, third works, fourth crashes... Although the database is ok !
tarmistead: UserTransaction are nearly unusable (check my other postings). Worst thing is that resources are not released at timeout when client dies - set your pool size to "1" and check it out!
Oops... did I said "unusable"? I mean "buggy". Pleasy forgive me, guys! Sorry!
OK, here is some code that illustrates what I'm trying:
UserTransaction tx = (UserTransaction)ctx.lookup("java:UserTransaction");
User moe = Homes.user.findByName("moe");
moe.setDescription("Just a guy");
The new description for user moe doesn't get stored to the DB. FYI, Homes is a convenience class that keeps static references to all my application Home objects.
Further info: application is CMP all the way.
Also FYI, my DD does not (yet) specify an transaction attributes. A quick glance at the 1.1 spec. makes it sound like this is mandatory, but so far JBoss hasn't complained either at deployment- or run-time. Could this be the reason for the behavior I've described? This is next on my list of things to try.
I am not sure if you have try this. In your session bean method, catch the exception and put this inside the catch statement.
where ctx is the SessionContext set when setSessionContext(SessionContext context) is called in the session bean.
I am using JBoss 3.0.0, MySQL 4.0.0, and mm.mysql-2.0.8 and I am having transaction problems as well. I am calling a method in a session facade bean with transaction support set to required. This one method calls a DAO method to perform a delete, then adds data back to the same table that a delete was performed on using a CMP entity bean (also with transaction support set to required). I get the duplicate entry error which means the session bean method doesn't recognize the DAO method as part of the transaction. When I use the same code and same versions of the database and jdbc drivers with Weblogic, it works fine.
Are you sure you have commit option B or C so jboss knows you're messing with the db behind its back?
I think the problem you encountered is exactly the same that I reported as a bug last november: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=486416&group_id=22866
I attached a very simple example bean, client and deployment descriptor with my posting (btw this example acts the expected way with the sun J2EE RI).
In the meantime I switched to jboss-2.4.4 and JDK 1.3.1_01, however the bug remained. The only configuration I found until now that changes the behaviour is the following:
Unfortunately this leads to other big problems.