MW>3) Using the long transaction example in the docs at MW>http://castor.exolab.org/long-transact.html, unless I stick the object MW>in the session (which I do not want to do), how do I actually get a MW>handle on info for the update phase? And don't I have to change access MW>modes? Unless I'm mistaken, I'd need to do: MW> MW> i. load object (use read-only access mode) MW> ii. display data, user decides to edit MW>iii. load object (use a write capable access mode) MW> iv. update objectMind you, update() is only called to bring an object fetched in one transaction into another transaction. Changes to an object are then persisted by simply calling commit().
I'm not sure I understand. The following is from the long transaction example:
// The servlet then calls updateCustomerInfo to update the
// last name for the indecisive customer.
public void updateCustomerInfo( CustomerInfo info ) {
db.begin();
db.update(info);
db.commit();
}
Doesn't db.update() update the object in the db? I don't understand what you mean by "called to bring an object fetched in one transaction into another transaction."
MW>But if this is the case, there's no way I can warn the user if the MW>object has changed between (i) and (iii). If there is a high potential for multiple users fetching the same data, this might be mitigated via special locking.
For example?
Thanks,
-Mark
