I remember thinking there might be a problem with option A. I'll take a look tonight - I probably left a comment in the command factory (where it keeps the read-ahead buffer.)
-danch Sacha Labourey wrote: > Hello, > > I've met a problem using <read-ahead> in 2.4.3. > > Situation: applet invoking a SLSB creating/modifying/updating entity beans. > > Test case: the applet ask the SLSB to modify the bean and then ask him to > return a data object containing the content of this entity beans (2 > distincts calls). > > Depending on the value of <read-ahead>, and commit-option (and maybe of > <tuned-updates> but I am not sure), the second call returns the *old* value! > The database is correctly updated but the SLSB, when asking for the bean > content, it receives the old content. If I redeploy the bean, I receive the > correct state. Switching from commit-option A to commit-option C has solved > the problem. > > So, is commit-option A correctly working with <read-ahead>? > > Cheers, > > > > Sacha > > > > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
