Home » Modeling » EMF » [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey
| |
| Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1016670 is a reply to message #1016126] |
Thu, 07 March 2013 10: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
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 |
 Erdal Karaca
Messages: 854
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:11Am 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 |
|
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
>
>
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 |
Erdal Karaca
Messages: 854
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 |
|
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.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO/Audtigin] CDORevisionDelta vs. CDORevisionKey [message #1020513 is a reply to message #1016971] |
Mon, 18 March 2013 10:44 |
Erdal Karaca
Messages: 854
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:06Am 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 #1031022 is a reply to message #1023914] |
Mon, 01 April 2013 04:20 |
|
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!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:23:53 GMT 2024
Powered by FUDForum. Page generated in 0.04914 seconds |
] 
Search
Help
Register
Login
Home
