Bruce,
let me try to state an example to see if I'm on the right track
how to handle long transactions.
Scenario: Web-based application with the ability to select and edit
an object. The object implements TimeStampable.
While a user edits an object, the object should be selectable
(for read) by other users.
1. Selection
User selects an object for edit.
db.begin();
OQLQuery oql = db.getOQLQuery(stmt);
QueryResults qr = oql.execute(Database.ReadOnly);
Object bean = qr.next();
db.commit();
2. Edit
User decides to edit the object.
Currently, we do not do anything here. Should we?
3. Update
db.begin();
// db.lock(bean) should go here, shouldn't it?
db.update(bean);
db.commit();
Currently, we are not using db.lock(), but experienced
"Transaction already in progress" exceptions if users try to update
the same object.
One more thing:
the lock() doc says:
* If the timeout has elapsed or a deadlock has been detected,
* an exception will be thrown but the current lock will be retained.
How do you set the timeout? Is there also some 'unlock' functionality
in case the operation must be cancelled?
Thanks,
Heiko Erhardt
skynamics AG
www.skynamics.com
> -----Original Message-----
> From: Bruce Snyder [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 5:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Multithreading JDO usage questions
>
>
> 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
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
