Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey
[CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016126] Tue, 05 March 2013 07:42 Go to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Hi all,
I have a WriteAccessHandler that listens for object modifications:

org.eclipse.emf.cdo.server.IRepository.WriteAccessHandler.handleTransactionAfterCommitted(ITransaction, CommitContext, OMMonitor)

I am calling CDOObjectHistory.getElements() to retrieve all revision deltas of the modified EObjects/CDOObjects.

The first call returns all changes (CDORevisionDelta) as expected. The second or the next time I execute the same code to get the changes, I only get CDORevisionKey.

When do have to expect what should be returned: CDORevisionKey or CDORevisionDelta?

Thanks.
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016127 is a reply to message #1016126] Tue, 05 March 2013 07:47 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
BTW.: CDOObjectHistory.getElements() (or code to retrieve history of a modified object) is called in a different thread. The only information that is available is the object that changed, so I dont use org.eclipse.emf.cdo.server.IStoreAccessor.CommitContext.getDirtyObjectDeltas() when WriteAccessHandler.handleTransactionAfterCommitted() is called.

Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016670 is a reply to message #1016126] Thu, 07 March 2013 10:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 05.03.2013 08:42, schrieb Erdal Karaca:
> Hi all,
> I have a WriteAccessHandler that listens for object modifications:
>
> org.eclipse.emf.cdo.server.IRepository.WriteAccessHandler.handleTransactionAfterCommitted(ITransaction, CommitContext,
> OMMonitor)
So, that's on the server side.

> I am calling CDOObjectHistory.getElements() to retrieve all revision deltas of the modified EObjects/CDOObjects.
Is that on the client side? How's the WriteAccessHandler related?

> The first call returns all changes (CDORevisionDelta) as expected.
No, CDOObjectHistory.getElements() returns CDOCommitInfo[].

> The second or the next time I execute the same code to get the changes, I only get CDORevisionKey.
Maybe you should show your complete code for this because the above hints seem to be incomplete or wrong.

> When do have to expect what should be returned: CDORevisionKey or CDORevisionDelta?
CDOCommitInfo.getChangedObjects() contains deltas if they are available, revision (delta) keys otherwise. Deltas are
available if

1) they've been created at the client side, e.g., during a local commit or
2) the client uses at least PassiveUpdateMode.CHANGES or
3) the client has subscribed to change notifications for the respective object (see
CDOView.Options.setChangeSubscriptionPolicy).

CDOCommitInfo.getNewObjects() contains revisions if they are available, revision keys otherwise. Revisions are available if

1) they've been created at the client side, e.g., during a local commit or
2) the client uses PassiveUpdateMode.ADDITIONS.

I agree that for a CDOCommitHistory element it is desirable to always get access to the revisions and deltas, even if
they originate from CDOSessionImpl.invalidate() and none of the 5 criteria above match. Please submit a bugzilla so that
I can look at it.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016900 is a reply to message #1016670] Fri, 08 March 2013 07:33 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Hi Eike,
This is the code snippet:

      CDOObject cdoObject = ... //object to get the history for
      CDOCommitInfo[] elements = cdoObjectHistory.getElements();

      for (int i = elements.length - 1; i >= 0; i--) {
        CDOCommitInfo ci = elements[i];

        List<CDORevisionKey> changedObjects = ci.getChangedObjects();
        List<CDORevisionKey> keys = new ArrayList<CDORevisionKey>();

        for (CDORevisionKey cdoRevisionKey : changedObjects) {
          if (!(cdoRevisionKey instanceof CDORevisionDelta)){
            continue;
          }
          
          CDOID targetId = cdoRevisionKey.getID();

          if (!targetId.equals(cdoObject.cdoID())) {
            continue;
          }

          keys.add(cdoRevisionKey);
        }

        if (!keys.isEmpty()) {
          // if any, then all deltas of cdoObject are now in the keys array
          // which we process later
        }
      }


As said, the first time the object (cdoObject) is changed, keys will contain all deltas, but the next time (not always the second time), it is empty as ci.getChangedObjects() doesnt contain any deltas.
I just want to monitor on the server side all changes to the objects, then and log them (old/new value of changed objects).
If doing this all in the write access handler after transaction is committed, I get timeout exceptions. So, the idea was to just remember the changed object (CDOID) and process its history 'later' (in a separate thread).

Eike Stepper wrote on Thu, 07 March 2013 11:11
Am 05.03.2013 08:42, schrieb Erdal Karaca:
> Hi all,
> I have a WriteAccessHandler that listens for object modifications:
>
> org.eclipse.emf.cdo.server.IRepository.WriteAccessHandler.handleTransactionAfterCommitted(ITransaction, CommitContext,
> OMMonitor)
So, that's on the server side.

> I am calling CDOObjectHistory.getElements() to retrieve all revision deltas of the modified EObjects/CDOObjects.
Is that on the client side? How's the WriteAccessHandler related?

> The first call returns all changes (CDORevisionDelta) as expected.
No, CDOObjectHistory.getElements() returns CDOCommitInfo[].

> The second or the next time I execute the same code to get the changes, I only get CDORevisionKey.
Maybe you should show your complete code for this because the above hints seem to be incomplete or wrong.

> When do have to expect what should be returned: CDORevisionKey or CDORevisionDelta?
CDOCommitInfo.getChangedObjects() contains deltas if they are available, revision (delta) keys otherwise. Deltas are
available if

1) they've been created at the client side, e.g., during a local commit or
2) the client uses at least PassiveUpdateMode.CHANGES or
3) the client has subscribed to change notifications for the respective object (see
CDOView.Options.setChangeSubscriptionPolicy).

CDOCommitInfo.getNewObjects() contains revisions if they are available, revision keys otherwise. Revisions are available if

1) they've been created at the client side, e.g., during a local commit or
2) the client uses PassiveUpdateMode.ADDITIONS.

I agree that for a CDOCommitHistory element it is desirable to always get access to the revisions and deltas, even if
they originate from CDOSessionImpl.invalidate() and none of the 5 criteria above match. Please submit a bugzilla so that
I can look at it.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016932 is a reply to message #1016900] Fri, 08 March 2013 09:12 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 08.03.2013 08:33, schrieb Erdal Karaca:
> Hi Eike,
> This is the code snippet:
>
>
> CDOObject cdoObject = ... //object to get the history for
> CDOCommitInfo[] elements = cdoObjectHistory.getElements();
>
> for (int i = elements.length - 1; i >= 0; i--) {
> CDOCommitInfo ci = elements[i];
>
> List<CDORevisionKey> changedObjects = ci.getChangedObjects();
> List<CDORevisionKey> keys = new ArrayList<CDORevisionKey>();
>
> for (CDORevisionKey cdoRevisionKey : changedObjects) {
> if (!(cdoRevisionKey instanceof CDORevisionDelta)){
> continue;
> }
> CDOID targetId = cdoRevisionKey.getID();
>
> if (!targetId.equals(cdoObject.cdoID())) {
> continue;
> }
>
> keys.add(cdoRevisionKey);
> }
>
> if (!keys.isEmpty()) {
> // if any, then all deltas of cdoObject are now in the keys array
> // which we process later
> }
> }
>
>
> As said, the first time the object (cdoObject) is changed, keys will contain all deltas, but the next time (not always
> the second time), it is empty as ci.getChangedObjects() doesnt contain any deltas.
> I just want to monitor on the server side all changes to the objects, then and log them (old/new value of changed
> objects).
> If doing this all in the write access handler after transaction is committed, I get timeout exceptions. So, the idea
> was to just remember the changed object (CDOID) and process its history 'later' (in a separate thread).
So you're opening a CDOView on the server just to log changes? That doesn't seem optimal. Why don't you register a write
access handler and place the commit context infos needed for your logging into a queue, which is then processed
asynchronously?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Eike Stepper wrote on Thu, 07 March 2013 11:11
>> Am 05.03.2013 08:42, schrieb Erdal Karaca:
>> > Hi all,
>> > I have a WriteAccessHandler that listens for object modifications:
>> >
>> > org.eclipse.emf.cdo.server.IRepository.WriteAccessHandler.handleTransactionAfterCommitted(ITransaction,
>> CommitContext, > OMMonitor)
>> So, that's on the server side.
>>
>> > I am calling CDOObjectHistory.getElements() to retrieve all revision deltas of the modified EObjects/CDOObjects.
>> Is that on the client side? How's the WriteAccessHandler related?
>>
>> > The first call returns all changes (CDORevisionDelta) as expected. No, CDOObjectHistory.getElements() returns
>> CDOCommitInfo[].
>>
>> > The second or the next time I execute the same code to get the changes, I only get CDORevisionKey.
>> Maybe you should show your complete code for this because the above hints seem to be incomplete or wrong.
>>
>> > When do have to expect what should be returned: CDORevisionKey or CDORevisionDelta?
>> CDOCommitInfo.getChangedObjects() contains deltas if they are available, revision (delta) keys otherwise. Deltas are
>> available if
>>
>> 1) they've been created at the client side, e.g., during a local commit or
>> 2) the client uses at least PassiveUpdateMode.CHANGES or
>> 3) the client has subscribed to change notifications for the respective object (see
>> CDOView.Options.setChangeSubscriptionPolicy).
>>
>> CDOCommitInfo.getNewObjects() contains revisions if they are available, revision keys otherwise. Revisions are
>> available if
>>
>> 1) they've been created at the client side, e.g., during a local commit or
>> 2) the client uses PassiveUpdateMode.ADDITIONS.
>>
>> I agree that for a CDOCommitHistory element it is desirable to always get access to the revisions and deltas, even if
>> they originate from CDOSessionImpl.invalidate() and none of the 5 criteria above match. Please submit a bugzilla so
>> that I can look at it.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>
>
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016938 is a reply to message #1016932] Fri, 08 March 2013 09:35 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Eike Stepper wrote on Fri, 08 March 2013 10:12

> If doing this all in the write access handler after transaction is committed, I get timeout exceptions. So, the idea
> was to just remember the changed object (CDOID) and process its history 'later' (in a separate thread).
So you're opening a CDOView on the server just to log changes? That doesn't seem optimal. Why don't you register a write
access handler and place the commit context infos needed for your logging into a queue, which is then processed
asynchronously?

Cheers
/Eike


I thought of that option, first, but there will be "many" clients connected changing "many" objects at the same time which may increase memory consumption.
So, the easiest way seemed to be to just queue the CDOID which changed, then, query the history of that object asynchronously (though, performance may decrease instead).
If it does not work as expected I will switch to your solution.
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016971 is a reply to message #1016938] Fri, 08 March 2013 12:06 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 08.03.2013 10:35, schrieb Erdal Karaca:
> Eike Stepper wrote on Fri, 08 March 2013 10:12
>> > If doing this all in the write access handler after transaction is committed, I get timeout exceptions. So, the idea > was to just remember the changed
>> object (CDOID) and process its history 'later' (in a separate thread).
>> So you're opening a CDOView on the server just to log changes? That doesn't seem optimal. Why don't you register a
>> write access handler and place the commit context infos needed for your logging into a queue, which is then processed
>> asynchronously?
>>
>> Cheers
>> /Eike
>
>
> I thought of that option, first, but there will be "many" clients connected changing "many" objects at the same time
> which may increase memory consumption.
> So, the easiest way seemed to be to just queue the CDOID
Even that you can do with a write access handler instead of a full-blown CDOView.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



> which changed, then, query the history of that object asynchronously (though, performance may decrease instead).
> If it does not work as expected I will switch to your solution.
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1020513 is a reply to message #1016971] Mon, 18 March 2013 10:44 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Hi Eike,
Just an update: if I rely on the CDORevisionDeltas that are provided in the transaction handler's handleTransactionAfterCommitted(), I do not get the old value.
This is a problem as I have to determine it somehow.

I think we discussed this in another forum post: is there a way to "force" the CDOFeatureDelta to also contain the old value without using a fully-featured CDOView (just what is provided in handleTransactionAfterCommitted())?

Thanks!


Eike Stepper wrote on Fri, 08 March 2013 13:06
Am 08.03.2013 10:35, schrieb Erdal Karaca:
> Eike Stepper wrote on Fri, 08 March 2013 10:12
>> > If doing this all in the write access handler after transaction is committed, I get timeout exceptions. So, the idea > was to just remember the changed
>> object (CDOID) and process its history 'later' (in a separate thread).
>> So you're opening a CDOView on the server just to log changes? That doesn't seem optimal. Why don't you register a
>> write access handler and place the commit context infos needed for your logging into a queue, which is then processed
>> asynchronously?
>>
>> Cheers
>> /Eike
>
>
> I thought of that option, first, but there will be "many" clients connected changing "many" objects at the same time
> which may increase memory consumption.
> So, the easiest way seemed to be to just queue the CDOID
Even that you can do with a write access handler instead of a full-blown CDOView.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



> which changed, then, query the history of that object asynchronously (though, performance may decrease instead).
> If it does not work as expected I will switch to your solution.

Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1021225 is a reply to message #1020513] Tue, 19 March 2013 17:28 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 18.03.2013 11:44, schrieb Erdal Karaca:
> Hi Eike,
> Just an update: if I rely on the CDORevisionDeltas that are provided in the transaction handler's
> handleTransactionAfterCommitted(), I do not get the old value.
In an auditing or branching repository you can always ask for the revision of an object that a revision delta is based
on. In non-auditing repositories you could remember the old revisions in handleTransactionBeforeCommitting().

> This is a problem as I have to determine it somehow.
>
> I think we discussed this in another forum post: is there a way to "force" the CDOFeatureDelta to also contain the old
> value without using a fully-featured CDOView (just what is provided in handleTransactionAfterCommitted())?
No, the CDO server doesn't need this information and it can be very expensive to transmit it over the wire.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1023914 is a reply to message #1021225] Mon, 25 March 2013 13:03 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Hi Eike,
One more problem when processing the revision deltas asynchronously:

Caused by: org.eclipse.emf.cdo.util.CommitException: Rollback in HibernateStore: org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock objects within 1000 milli seconds
       at org.eclipse.net4j.util.concurrent.RWOLockManager.wait(RWOLockManager.java:434)
       at org.eclipse.net4j.util.concurrent.RWOLockManager.lock2(RWOLockManager.java:98)
       at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:865)
       at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:515)
       at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:46)
       at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
       at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
       at org.eclipse.emf.cdo.internal.server.Repository.commitUnsynced(Repository.java:917)
       at org.eclipse.emf.cdo.internal.server.Repository.commit(Repository.java:910)
       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:295)
       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:97)
       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
       at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
       at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
       at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
       at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
       at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
       at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
       at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
       at java.lang.Thread.run(Unknown Source)

       at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:84)
       at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1181)
       at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1205)



We queue the revision deltas and process them in another thread. In the other thread we create new objects and commit them, which leads to the timeout exception.
Do you have any ideas/hints what could be happening here?

Thanks!
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1023935 is a reply to message #1023914] Mon, 25 March 2013 13:47 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Just debugged to that line and the locked objects list (org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockedObjects) contains the resource.
Any suggestions how to work around this?

Erdal Karaca wrote on Mon, 25 March 2013 14:03
Hi Eike,
One more problem when processing the revision deltas asynchronously:

Caused by: org.eclipse.emf.cdo.util.CommitException: Rollback in HibernateStore: org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock objects within 1000 milli seconds
       at org.eclipse.net4j.util.concurrent.RWOLockManager.wait(RWOLockManager.java:434)
       at org.eclipse.net4j.util.concurrent.RWOLockManager.lock2(RWOLockManager.java:98)
       at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:865)
       at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:515)
       at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:46)
       at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
       at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
       at org.eclipse.emf.cdo.internal.server.Repository.commitUnsynced(Repository.java:917)
       at org.eclipse.emf.cdo.internal.server.Repository.commit(Repository.java:910)
       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:295)
       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:97)
       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
       at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
       at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
       at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
       at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
       at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
       at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
       at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
       at java.lang.Thread.run(Unknown Source)

       at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:84)
       at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1181)
       at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1205)



We queue the revision deltas and process them in another thread. In the other thread we create new objects and commit them, which leads to the timeout exception.
Do you have any ideas/hints what could be happening here?

Thanks!

Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1024436 is a reply to message #1023935] Tue, 26 March 2013 07:54 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
To sum it all up:

- Open new session on client side
- Open new transaction 1 on client side
- Open new session on server side
- Open new transaction 2 on server side

- change some objects on client and commit transaction 1
- on server side queue InternalCDORevisionDeltas and process asynchronously, i.e. create new objects and commit transaction 2 (for every new object) in a separate thread

- while the InternalCDORevisionDeltas are processed, change more objects on client side and commit transaction 1
==> org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock objects within 1000 milli seconds

This only happens if just one single Resource is involved. If, for example, the newly created objects on server side are added to another Resource, there is no timeout exception.
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1024459 is a reply to message #1023935] Tue, 26 March 2013 08:04 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
To sum it all up:

1. create new session and transaction 1 on client side
2. create new session and transaction 2 on server side
3. change some objects on client side and commit transaction 1
4. on server side, in WriteAccessHandler.handleTransactionAfterCommitted, queue all InternalCDORevisionDeltas and process them asynchronously in a separate thread
-> in the other thread, create new objects and add them to the same Resource the changed objects are contained in, commit transaction 2
5. while the asynchronous processing of the revision deltas is still running, try to change other objects on client side and commit transaction 1
-> org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock objects within 1000 milli seconds

The timeout exception only occures if using one Resource. If the new objects created at client side are added to a different Resource, there is no timeout exception.
Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1031022 is a reply to message #1023914] Mon, 01 April 2013 04:20 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Hi Erdal,

Sorry for the late reply, I've just returned from the EclipseCon in Boston.

I'm not exactly sure what you're doing in what exact order but if the locks could not be acquired you either need to try
longer (please submit an enhancement request to make the lock timeout configurable) or just try it again a little later.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 25.03.2013 14:03, schrieb Erdal Karaca:
> Hi Eike,
> One more problem when processing the revision deltas asynchronously:
>
>
> Caused by: org.eclipse.emf.cdo.util.CommitException: Rollback in HibernateStore:
> org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock objects within 1000 milli seconds
> at org.eclipse.net4j.util.concurrent.RWOLockManager.wait(RWOLockManager.java:434)
> at org.eclipse.net4j.util.concurrent.RWOLockManager.lock2(RWOLockManager.java:98)
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:865)
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:515)
> at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:46)
> at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
> at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
> at org.eclipse.emf.cdo.internal.server.Repository.commitUnsynced(Repository.java:917)
> at org.eclipse.emf.cdo.internal.server.Repository.commit(Repository.java:910)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:295)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:97)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
> at
> org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:84)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1181)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1205)
>
>
>
> We queue the revision deltas and process them in another thread. In the other thread we create new objects and commit
> them, which leads to the timeout exception.
> Do you have any ideas/hints what could be happening here?
>
> Thanks!
Previous Topic:Error in Combining acceleo project with jboss errai and gwt
Next Topic:[CDO] Error initializing server for PostgreSQL DB in CDO M6
Goto Forum:
  


Current Time: Sun Dec 21 12:55:03 GMT 2014

Powered by FUDForum. Page generated in 0.02285 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software