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
