I investigated this more and found that it was a bug in XDoclet that generated implementations of getData() in entity beans with overly optimistic lazy evaluations. JBoss works just fine, but I had to change XDoclet's template files. I guess this problem is fixed in later XDoclet versions, but we sadly have to use an old one.
Just for the record. Martin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Scott M > Stark > Sent: Saturday, September 20, 2003 3:56 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] commit-option A: CMP fields not updated bug? > > > I don't see this behavior so submit a bug report with an example > to sourceforge: > http://sourceforge.net/tracker/?group_id=22866&atid=376685 > > so we can look into your particular case. > > -- > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > Martin Vilcans wrote: > > > I've got a big problem with commit-option A and CMP beans and > it looks like a JBoss bug, but as I haven't found anything about > it in the bug tracker or the mailing list, it might be that I'm > doing something wrong. > > > > The problem is that when I call a CMP setter on a bean with > commit-option A, the new value is correctly stored in the > database, but the value is not updated in the cached bean. So if > I call for instance setFoo(42), the foo column in the database is > updated to 42, but if I then call getFoo(), I get the old value > back. If I flush the EJB cache or simply restart the server, the > correct value is fetched from the database, and getFoo() returns > the correct value. > > > > One weirdness is that if I call getFoo() immediately after > setFoo() (in the same transaction?) I get the correct value back. > It's like the EJB is rolled back at the end of the transaction. > > > > The behaviour is the same no matter if I call the setters > inside or outside a transaction when I call the EEJB through a > local interface. If I call it through the remote interface, I get > "java.lang.IllegalStateException: There is no tranaction (sic!) > associated with the current thread" when I call the setter > without a transaction, and the same behaviour as with the local > interface if I call it within a transaction. > > > > I've tried both JBoss 3.2.1 and 3.2.2RC3 and got the same results. > > > > Here are the relevant parts of the deployment of one of the beans: > > > > jboss.xml: > > > > <entity> > > <ejb-name>CalendarItem</ejb-name> > > <jndi-name>CalendarItem</jndi-name> > > <local-jndi-name>CalendarItemLocal</local-jndi-name> > > <read-only>false</read-only> > > <configuration-name>CMP 2.x and Cache</configuration-name> > > </entity> > > . > > . > > <container-configurations> > > <container-configuration extends="Standard CMP 2.x EntityBean"> > > <container-name>CMP 2.x and Cache</container-name> > > <commit-option>A</commit-option> > > </container-configuration> > > </container-configurations> > > > > > > jbosscmp-jdbc.xml: > > > > <entity> > > <ejb-name>CalendarItem</ejb-name> > > <create-table>true</create-table> > > <remove-table>false</remove-table> > > <read-only>false</read-only> > > <table-name>calendarItem</table-name> > > > > <cmp-field> > > <field-name>body</field-name> > > <column-name>body</column-name> > > </cmp-field> > > <cmp-field> > > <field-name>celebrityId</field-name> > > <column-name>celebrityId</column-name> > > <jdbc-type>SMALLINT</jdbc-type> > > <sql-type>SMALLINT UNSIGNED</sql-type> > > </cmp-field> > > <cmp-field> > > <field-name>day</field-name> > > <column-name>day</column-name> > > </cmp-field> > > <cmp-field> > > <field-name>ordinal</field-name> > > <column-name>ordinal</column-name> > > </cmp-field> > > <cmp-field> > > <field-name>week</field-name> > > <column-name>week</column-name> > > </cmp-field> > > > > The database is MySQL 4.0.13 through > mysql-connector-java-3.0.8-stable-bin.jar. > > > > If this is a JBoss bug, I can't see how I can be the only one > with this problem. If noone recognizes this problem, I'll try to > create a simple test case to reproduce this behaviour, but for > now I just need to know if I'm alone. :-) > > > > Martin > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
