Eclipse Community Forums: EMF » [CDO] Explicit Locking feature.

Help

Home

Home » Modeling » EMF » [CDO] Explicit Locking feature.

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] Explicit Locking feature. [message #427335]

Thu, 12 February 2009 14:03

Stephane fournier

Messages: 340
Registered: July 2009

Senior Member

Hi,

I tested the "write lock" feature.
Does an API exist to check if an object is already locked (who (cdo
session ?) owns the lock, which lock type,...) ?

What is the purpose of the "read lock" ? I did not see the difference
with a write lock ...

Stephane.

--

Report message to a moderator

Re: [CDO] Explicit Locking feature. [message #427337 is a reply to message #427335]

Thu, 12 February 2009 14:58

Victor Roldan Betancort

Messages: 524
Registered: July 2009

Senior Member

Stéphane,

> I tested the "write lock" feature.
> Does an API exist to check if an object is already locked (who (cdo
> session ?) owns the lock, which lock type,...) ?

in org.eclipse.emf.cdo.CDOObject you have:

/**
* Returns the read lock associated with this object.
*
* @return Never <code>null</code>.
* @since 2.0
*/
public CDOLock cdoReadLock();

/**
* Returns the write lock associated with this object.
*
* @return Never <code>null</code>.
* @since 2.0
*/
public CDOLock cdoWriteLock();

I believe there is nothing that specifies "who owns the lock".

In org.eclipse.emf.cdo.view.CDOView you also have:

/**
* Reloads the given {@link CDOObject objects} from the repository.
*/
public int reload(CDOObject... objects);

public void lockObjects(Collection<? extends CDOObject> objects,
RWLockManager.LockType lockType, long timeout)
throws InterruptedException;

/**
* Unlocks the given locked objects of this view.
*/
public void unlockObjects(Collection<? extends CDOObject> objects,
RWLockManager.LockType lockType);

/**
* Unlocks all locked objects of this view.
*
* @since 2.0
*/
public void unlockObjects();

> What is the purpose of the "read lock" ? I did not see the difference
> with a write lock ...

I haven't tested much that new feature. I guess a "read lock" should
avoid others to retrieve certain CDOObject from the repository. Simon
McDuff developed this feature, maybe he can clarify better what is this
kind of lock supposed to do.

Cheers,
Víctor.

Report message to a moderator

Re: [CDO] Explicit Locking feature. [message #427339 is a reply to message #427337]

Thu, 12 February 2009 15:16

Simon Mc Duff

Messages: 596
Registered: July 2009

Senior Member

Hi Stephane,

The difference between read and lock is the following:

- Many Read locks could happen at the same time (From different views)
- cdoWriteLock is successful only if they have no readlock and nowriteLock
- cdoWriteLock could only happen from the same views.
- If a clientA modify objectA and clientB have a readLock on it... the
commit of clientA will fail. Since the commit manager will automatically
writeLock every Dirty Objects.

Is that help you Stephane ?

Report message to a moderator

Re: [CDO] Explicit Locking feature. [message #427342 is a reply to message #427339]

Thu, 12 February 2009 18:02

Stephane fournier

Messages: 340
Registered: July 2009

Senior Member

Simon & Victor,
Thanks for your helpful answers.

Simon, could you give me please an example of a typical usage of the
readLock.
If I clearly understood, a readLock allows its owner to avoid
modifications by another one.
Hence, multiples users reading an object can lock it to prevent other
ones to modify it while they are reading it.

The writeLock can be used to tell to other ones, the object is under
modifications.... A commit will happen...

Am I right Simon ?

Stéphane.

Simon Mc Duff wrote:
> Hi Stephane,
>
> The difference between read and lock is the following:
>
> - Many Read locks could happen at the same time (From different views)
> - cdoWriteLock is successful only if they have no readlock and nowriteLock
> - cdoWriteLock could only happen from the same views. - If a clientA
> modify objectA and clientB have a readLock on it... the commit of
> clientA will fail. Since the commit manager will automatically
> writeLock every Dirty Objects.
>
> Is that help you Stephane ?
>
>

--

Report message to a moderator

Re: [CDO] Explicit Locking feature. [message #427343 is a reply to message #427342]

Thu, 12 February 2009 18:42

Simon Mc Duff

Messages: 596
Registered: July 2009

Senior Member

Stéphane Fournier wrote:

> Simon & Victor,
> Thanks for your helpful answers.
You are welcome!

> Simon, could you give me please an example of a typical usage of the
> readLock.
If you want to calculates something on a bunch of objects.. and you do not
allow changes during that time..... otherwise your answer will not be
accurate. But you allo others to read them!! :-) I'm sure you can come up
with a better example.

> If I clearly understood, a readLock allows its owner to avoid
> modifications by another one.
Yes, it is exactly that.

> Hence, multiples users reading an object can lock it to prevent other
> ones to modify it while they are reading it.
Yes.

> The writeLock can be used to tell to other ones, the object is under
> modifications.... A commit will happen...
Yes this is one reason.

> Am I right Simon ?
Yes. Don't forget that each time you commit... the write lock is kicked-in
automatically.

> Stéphane.

> Simon Mc Duff wrote:
>> Hi Stephane,
>>
>> The difference between read and lock is the following:
>>
>> - Many Read locks could happen at the same time (From different views)
>> - cdoWriteLock is successful only if they have no readlock and nowriteLock
>> - cdoWriteLock could only happen from the same views. - If a clientA
>> modify objectA and clientB have a readLock on it... the commit of
>> clientA will fail. Since the commit manager will automatically
>> writeLock every Dirty Objects.
>>
>> Is that help you Stephane ?
>>
>>

> --

Report message to a moderator

Previous Topic:	Deploy EMF with Teneo in a servlet, ClassNotFoundException EPackage
Next Topic:	CDO adding object from sub-model

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon May 13 17:41:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter