This one time, at band camp, Mark Woon said: MW>Sorry, I meant implement TimeStampable.
Yes, that's fairly typical. MW>>MW>3) Using the long transaction example in the docs at MW>>MW>http://castor.exolab.org/long-transact.html, unless I stick the object MW>>MW>in the session (which I do not want to do), how do I actually get a MW>>MW>handle on info for the update phase? And don't I have to change access MW>>MW>modes? Unless I'm mistaken, I'd need to do: MW>>MW> MW>>MW> i. load object (use read-only access mode) MW>>MW> ii. display data, user decides to edit MW>>MW>iii. load object (use a write capable access mode) MW>>MW> iv. update object MW>> MW>>Mind you, update() is only called to bring an object fetched in one MW>>transaction into another transaction. Changes to an object are then MW>>persisted by simply calling commit(). MW>> MW> MW>I'm not sure I understand. The following is from the long transaction MW>example: MW> MW> // The servlet then calls updateCustomerInfo to update the MW> // last name for the indecisive customer. MW> public void updateCustomerInfo( CustomerInfo info ) { MW> db.begin(); MW> db.update(info); MW> db.commit(); MW> } MW> MW>Doesn't db.update() update the object in the db? I don't understand MW>what you mean by "called to bring an object fetched in one transaction MW>into another transaction." That's not how update() works. Notice the following text: // Three days passed, the indecisive customer finally agrees to // marry Joe. She changes her last name in the webpage and // clicked the "Submit" button on the webpage. The statement above would result in: 1) Changes to the info object e.g. info.setLastName( "Jones" ) 2) A call to updateCustomerInfo( info ). It's this call that then: a) starts a new transaction using begin() b) supply the current transaction with the most recent info object using update( info ) c) commit the changes to persistence using commit() For more info on update() see: http://castor.exolab.org/javadoc/org/exolab/castor/jdo/Database.html#update(java.lang.Object) MW>>MW>But if this is the case, there's no way I can warn the user if the MW>>MW>object has changed between (i) and (iii). MW>> MW>>If there is a high potential for multiple users fetching the same MW>>data, this might be mitigated via special locking. MW>> MW> MW>For example? If the app *only* offers a view of an object, utilize read only access. If the app is going to offer a view of an object and the possiblity to edit the object, utilize a read only query and then upgrade the lock using db.lock() only if the user decides to edit the object. Depending on the potential for two users to edit the same object simultaneously, utilize exclusive access or, if it's an extreme case, utilize database locked access. MW>Also, is it necessary to implement org.exolab.xastor.jdo.Persistent for MW>all object that I want to persist, or only if I need the callbacks? This is only necessary if you want to make use of Castor's callback mechanism. -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&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
