This one time, at band camp, tek1 said:
t>i have read through numerous past posts about the "Timestamp mismatch!"
t>problem with long transactions, but can't understand what is happening.
t>
t>basically, i have 2 servlets, ServletA and ServletB.
t>
t>ServletA retrieves an existing User from the database as follows:
t>
t> db.begin();
t> OQLQuery query = db.getOQLQuery(OQL_FIND_BY_LOGINID);
t> query.bind(data.getLoginId());
t> QueryResults results = query.execute();
t> if( results.size() > 1 ) {
t> throw new PMException("More than 1 object was returned.");
t> }
t> User user = null;
t> while( results.hasMore() ) {
t> user= (User)results.next();
t> }
t> db.commit();
t>
t>then this User object is stored in the session.
t>
t> req.getSession().setAttribute("user", user);
t>
t>
t>later, ServletB retrieves the user from the session and attempts to
t>Castor-update() it as follows:
t>
t>
t> db.begin();
t> User user = (User)req.getSession(false).getAttribute(SessionAttributes.USER);
t>-> db.update(user); // getting "Timestamp mismatch!" here
t> ...
t> // also, another persistable object tries to user the User object
t> Order order = new Order();
t> order.setUser(user);
t> db.create(order);
t> db.commit();
t>
t>
t>the User class implements the org.exolab.castor.jdo.TimeStampable interface
t>and the pertinent part of the mapping.xml definition for the User object is
t>as follows:
t>
t> <class name="User"
t> identity="id"
t> access="shared"
t> key-generator="UUID"
t> auto-complete="false">
t> <map-to
t> table="usr"
t> />
t> <cache-type
t> type="count-limited"
t> />
t> ...
t> </class>
t>
t>
t>i have read in the posts that the default count-limited is 100, and i have
t>not performed many database transactions to be even close to the limit of 100.
t>
t>the workaround that i'm using to temporarily solve the problem is:
t>
t> User user = (User)req.getSession(false).getAttribute("user");
t> user = (User)db.load(User.class,user.getId());
t>
t>but i would like to understand why db.update(user) is not working?
This seems to be bug #1107 rearing its head. On Friday, I checked in
a test case (TC60) for this bug against Oracle and MySQL. The problem
I'm having is that in one of my environments the test passes and in
another one it fails. I need to determine the differences between these
two environments.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
