Thomas,
thanks for the response. Having read further I get the feeling that there
is no reason why you would explicitly upgrade the lock - instead just let
Castor do it. What my question was though, was say I have something like
(psuedo-code):
results = query.execute();
firstResult = results.next();
// question - should I do this:
db.lock(firstResult);
// before this
firstResult.setSomething(different);
db.commit() // etc...
Also - the javadocs say the query.execute(short lockType) is
experimental... how stable is it? can I assume that in future versions it
will remain?
cheers
dim
On Thu, 20 Sep 2001, Thomas Yip wrote:
> If you don't know if you should upgrade the lock, then don't.
>
> You can specify the default access mode in the mapping.
> If shared mode is used, lock on modified object will be updated at the
> commit time.
> If lock upgrade failed, the transaction will be rollback.
>
>
> Thomas
>
> -----Original Message-----
> >From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, September 18, 2001 4:36 PM
> >To: [EMAIL PROTECTED]
> >Subject: [castor-dev] best practices?
> >
> >hey guys,
> >
> >I'm in the process of evaluating Castor, and am liking what I see this
> >far. I was wondering if there is a "best practices" doc somewhere,
> >outlining things like upgrading locks. Should I try and explicity upgrade
> >a lock before changing the data, or should I let Castor do it? I'm sure
> >there are other similar questions I haven't come across, so am proactively
> >looking for answers.
> >
> >To give a context to my question, we're probably going to migrate entity
> >beans to castor, pretty standard, but I'd kinda like to sit on the
> >fence. I figure if for a persistent object "Account" I had a session bean
> >"AccountPM" with the following methods:
> >
> > public void create(Account account);
> > public void remove(Account account);
> > public void lock(Account account);
> > public Account[] findByXXX( ... );
> >
> >then I could implement it either with castor or entity beans. The castor
> >impl is pretty obvious - just delegating. In an entity bean impl the
> >Account object is the DAO, not the entity bean. The findBy would return
> >the data object, and lock would behind the scenes repoint the data object
> >at the local interface for account...
> >
> >thats a pretty quick summary, but I think its workable... the key thing
> >obviously being lock - whilst I could have an entity bean impl upgrade the
> >lock transparently, its more work, so if the best practise in castor is to
> >do it explicity, then I wont worry about it...
> >
> >hope that makes sense.
> >
> >cheesr
> >dim
> >
> >-----------------------------------------------------------
> >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
>
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
