Is this something the testsuite wouldn't pick up? Perhaps you could provide something for the testsuite that demonstrates this.
Since you mention calling commit yourself I wonder if you are using bmp? If so are you aware that you currently need to get a connection after the start of the transaction and close it before the end? With cmt this means you cannot cache connections across method invocations. If you try to I think your transactions will get rolled back.
I am using CMP, and CMP with relationships, pretty much with out of the box beans. This was off a build from last week. Aparently someone else was getting the same thing. I actually walked the JBoss code in the debugger to prove to myself no exceptions were being thrown and that commit was never called on the connection befor it rolled back. Its deceptive because the bean gets created but not the databse entry, so any test that doesn't check for existence in the db will be fooled.
Anyways, I'm in the building phases of a product right now and I'm less worried about JBoss issues than I am about rolling out functionality. I can sit on top of any app server that has the latest EJB spec implemented. For now, I'll use my workaround. I just wanted to alert the JBoss dev team to the issue. This is alpha code after all and I need to be patient.
So are you saying that this sequence of calls, from a client, with commit option B or C, and tx Required, doesn't work?
[pk] id = ...
myHome h = ...
h.create(id);//should insert in tx 1
h.findbyPrimaryKey(id);//should reload from db in tx 2
I thought you were onto something because I never checked the commit option (although for my purposes it could be A). TX required is true and commit-option is B. Incidentally this commit option is what comes out of the box, so to speak.
Its been a few days and what I can remember is that upon creating the bean, the databse doesn't get populated. If I try to create it twice, an exception is thrown since the in memory bean exists (i did this for a sanity check before diving in). I'll have to check if the findByPrimaryKey works, because I used a different finder. Regardless of that, the fundamental problem is that the create didn't work. It doesn't matter what I do after - if I create the entity it should persist. And the database logs do show that a rollback is ALWAYS executed.
I will update the snapshot today and rebuild. The code base I have is a few days old now.