Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Problem with concurrent read and write threads
[CDO] Problem with concurrent read and write threads [message #987715] Tue, 27 November 2012 17:27 Go to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
I'm noticing a very strange behavior in the following test I made using concurrent access.
Scenario: I have 2 threads, 1 reader and 1 writer, executing concurrently. We never have write conflicts, because we have only 1 writer.
The threads are executing without any delay, because I want to see how CDO handles many requests. For each iteration, a new session is created.
During the test I get some exceptions (NPE). If I don't make the commit then there isn't any exception.

!ENTRY org.eclipse.net4j 4 0 2012-11-27 16:31:14.217
!MESSAGE NullPointerException
!STACK 0
java.lang.NullPointerException
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOBranch(CDODataInputImpl.java:188)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOCommitInfo(CDODataInputImpl.java:276)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificationIndication.indicating(CommitNotificationIndication.java:36)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndication.indicating(CDOClientIndication.java:56)
	at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
	at org.eclipse.net4j.signal.Indication.execute(Indication.java:51)
	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$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)


I checked and the writes didn't failed, everything was persisted.
Is this an "expected" behavior (let's say, a known limitation) when opening and closing so many CDOSession in a very short time? Or can we say it is a bug?
I attached the test java file.
Re: [CDO] Problem with concurrent read and write threads [message #987767 is a reply to message #987715] Wed, 28 November 2012 03:48 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 27.11.2012 18:27, schrieb Silvestre Martins:
> I'm noticing a very strange behavior in the following test I made using concurrent access.
> Scenario: I have 2 threads, 1 reader and 1 writer, executing concurrently. We never have write conflicts, because we have only 1 writer.
> The threads are executing without any delay, because I want to see how CDO handles many requests. For each iteration, a new session is created.
> During the test I get some exceptions (NPE). If I don't make the commit then there isn't any exception.
>
> !ENTRY org.eclipse.net4j 4 0 2012-11-27 16:31:14.217
> !MESSAGE NullPointerException
> !STACK 0
> java.lang.NullPointerException
> at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOBranch(CDODataInputImpl.java:188)
> at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOCommitInfo(CDODataInputImpl.java:276)
> at org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificationIndication.indicating(CommitNotificationIndication.java:36)
CommitNotificationIndication.indicating() is executed asynchronously on a client side after successful commits on the
server side. If the client has closed or is closing the session (with all the contained infrastructure such as the
branch manager) any kind of exception can possibly occur from the notification signal thread. They can all be ignored.

> at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndication.indicating(CDOClientIndication.java:56)
> at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java:51)
> 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$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
> I checked and the writes didn't failed, everything was persisted.
> Is this an "expected" behavior (let's say, a known limitation) when opening and closing so many CDOSession in a very short time? Or can we say it is a bug?
> I attached the test java file.
You may call it a known limitation, although the problem is really just the logging of the exception.

Cheers
/Eike

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


Re: [CDO] Problem with concurrent read and write threads when creating too many sessions [message #988420 is a reply to message #987767] Thu, 29 November 2012 20:41 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
Eike Stepper wrote on Tue, 27 November 2012 22:48
Am 27.11.2012 18:27, schrieb Silvestre Martins:
> I'm noticing a very strange behavior in the following test I made using concurrent access.
> Scenario: I have 2 threads, 1 reader and 1 writer, executing concurrently. We never have write conflicts, because we have only 1 writer.
> The threads are executing without any delay, because I want to see how CDO handles many requests. For each iteration, a new session is created.
> During the test I get some exceptions (NPE). If I don't make the commit then there isn't any exception.
>
> !ENTRY org.eclipse.net4j 4 0 2012-11-27 16:31:14.217
> !MESSAGE NullPointerException
> !STACK 0
> java.lang.NullPointerException
> at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOBranch(CDODataInputImpl.java:188)
> at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOCommitInfo(CDODataInputImpl.java:276)
> at org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificationIndication.indicating(CommitNotificationIndication.java:36)
CommitNotificationIndication.indicating() is executed asynchronously on a client side after successful commits on the
server side. If the client has closed or is closing the session (with all the contained infrastructure such as the
branch manager) any kind of exception can possibly occur from the notification signal thread. They can all be ignored.

> at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndication.indicating(CDOClientIndication.java:56)
> at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java:51)
> 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$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
> I checked and the writes didn't failed, everything was persisted.
> Is this an "expected" behavior (let's say, a known limitation) when opening and closing so many CDOSession in a very short time? Or can we say it is a bug?
> I attached the test java file.
You may call it a known limitation, although the problem is really just the logging of the exception.

Cheers
/Eike

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


So you don't recommend to create a bugzilla for this. This is ok for me, because I don't expect to have this exception very often when running in a normal usage.

BTW, do you know about any example of a typical implementation of CDO in a web application (the CDO client would be in the server side)? I mean, how would, in these case, the CDO Session be used? Mapping the CDO session to the user session seems to be what makes more sense to me, but it may cause the session to stay opened for a long time. Is the CDO session ready for this kind of usage?
In the other hand, creating a CDO Session for each request, may end with too many CDO sessions being created.
Another usage could be to create a CDO session for each "conversation", like when starting a wizard workflow or editing the details of an entity.
Re: [CDO] Problem with concurrent read and write threads when creating too many sessions [message #988475 is a reply to message #988420] Fri, 30 November 2012 06:43 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 29.11.2012 21:41, schrieb Silvestre Martins:
> BTW, do you know about any example of a typical implementation of CDO in a web application (the CDO client would be in
> the server side)?
Yes ;-)

> I mean, how would, in these case, the CDO Session be used? Mapping the CDO session to the user session seems to be
> what makes more sense to me, but it may cause the session to stay opened for a long time. Is the CDO session ready for
> this kind of usage?
> In the other hand, creating a CDO Session for each request, may end with too many CDO sessions being created.
> Another usage could be to create a CDO session for each "conversation", like when starting a wizard workflow or
> editing the details of an entity.
CDOSession is kind of an expensive facility because it does authentication/negotiation and it maintains a
CDORevisionCache (plus other caches). If you don't care about session.getUserID() being used for the commits of all
users I'd recommend to use one CDOSession for all users and open CDOViews or CDOTransactions per HttpSession (or per
HttpRequest).

Cheers
/Eike

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


Re: [CDO] Problem with concurrent read and write threads when creating too many sessions [message #988601 is a reply to message #988475] Fri, 30 November 2012 16:26 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
Eike Stepper wrote on Fri, 30 November 2012 01:43
Am 29.11.2012 21:41, schrieb Silvestre Martins:
> BTW, do you know about any example of a typical implementation of CDO in a web application (the CDO client would be in
> the server side)?
Yes Wink

> I mean, how would, in these case, the CDO Session be used? Mapping the CDO session to the user session seems to be
> what makes more sense to me, but it may cause the session to stay opened for a long time. Is the CDO session ready for
> this kind of usage?
> In the other hand, creating a CDO Session for each request, may end with too many CDO sessions being created.
> Another usage could be to create a CDO session for each "conversation", like when starting a wizard workflow or
> editing the details of an entity.
CDOSession is kind of an expensive facility because it does authentication/negotiation and it maintains a
CDORevisionCache (plus other caches). If you don't care about session.getUserID() being used for the commits of all
users I'd recommend to use one CDOSession for all users and open CDOViews or CDOTransactions per HttpSession (or per
HttpRequest).


What about concurrency? I want the users to be able to perform concurrent modifications. Can we have concurrent transactions within same session? I assumed we can't.
More, I want the users to be able to make several changes (like the wizard example) and then perform a save (commit) on the DB. I don't want other users to see the changes before user presses "save".
Re: [CDO] Problem with concurrent read and write threads when creating too many sessions [message #988610 is a reply to message #988601] Fri, 30 November 2012 17:07 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 30.11.2012 17:26, schrieb Silvestre Martins:
> Eike Stepper wrote on Fri, 30 November 2012 01:43
>> Am 29.11.2012 21:41, schrieb Silvestre Martins:
>> > BTW, do you know about any example of a typical implementation of CDO in a web application (the CDO client would be
>> in > the server side)? Yes ;)
>>
>> > I mean, how would, in these case, the CDO Session be used? Mapping the CDO session to the user session seems to be
>> > what makes more sense to me, but it may cause the session to stay opened for a long time. Is the CDO session ready
>> for > this kind of usage?
>> > In the other hand, creating a CDO Session for each request, may end with too many CDO sessions being created.
>> > Another usage could be to create a CDO session for each "conversation", like when starting a wizard workflow or >
>> editing the details of an entity.
>> CDOSession is kind of an expensive facility because it does authentication/negotiation and it maintains a
>> CDORevisionCache (plus other caches). If you don't care about session.getUserID() being used for the commits of all
>> users I'd recommend to use one CDOSession for all users and open CDOViews or CDOTransactions per HttpSession (or per
>> HttpRequest).
>
>
> What about concurrency? I want the users to be able to perform concurrent modifications. Can we have concurrent
> transactions within same session? I assumed we can't.
Sure, you can. As many views and/or transactions as you want.

> More, I want the users to be able to make several changes (like the wizard example) and then perform a save (commit)
> on the DB. I don't want other users to see the changes before user presses "save".
No problem, CDOTransactions (and the model instance they provide) are fully separated from each other.

Cheers
/Eike

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


Re: [CDO] Problem with concurrent read and write threads when creating too many sessions [message #988618 is a reply to message #988610] Fri, 30 November 2012 17:32 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 84
Registered: July 2009
Member
Eike Stepper wrote on Fri, 30 November 2012 12:07
Am 30.11.2012 17:26, schrieb Silvestre Martins:
> Eike Stepper wrote on Fri, 30 November 2012 01:43
>> Am 29.11.2012 21:41, schrieb Silvestre Martins:
>> > BTW, do you know about any example of a typical implementation of CDO in a web application (the CDO client would be
>> in > the server side)? Yes Wink
>>
>> > I mean, how would, in these case, the CDO Session be used? Mapping the CDO session to the user session seems to be
>> > what makes more sense to me, but it may cause the session to stay opened for a long time. Is the CDO session ready
>> for > this kind of usage?
>> > In the other hand, creating a CDO Session for each request, may end with too many CDO sessions being created.
>> > Another usage could be to create a CDO session for each "conversation", like when starting a wizard workflow or >
>> editing the details of an entity.
>> CDOSession is kind of an expensive facility because it does authentication/negotiation and it maintains a
>> CDORevisionCache (plus other caches). If you don't care about session.getUserID() being used for the commits of all
>> users I'd recommend to use one CDOSession for all users and open CDOViews or CDOTransactions per HttpSession (or per
>> HttpRequest).
>
>
> What about concurrency? I want the users to be able to perform concurrent modifications. Can we have concurrent
> transactions within same session? I assumed we can't.
Sure, you can. As many views and/or transactions as you want.

> More, I want the users to be able to make several changes (like the wizard example) and then perform a save (commit)
> on the DB. I don't want other users to see the changes before user presses "save".
No problem, CDOTransactions (and the model instance they provide) are fully separated from each other.


I thought that CDOTransactions shared the same objects from CDOSession cache. In this case it could implement is as you suggested.
Thanks.
Re: [CDO] Problem with concurrent read and write threads when creating too many sessions [message #988621 is a reply to message #988618] Fri, 30 November 2012 17:38 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 30.11.2012 18:32, schrieb Silvestre Martins:
> I thought that CDOTransactions shared the same objects from CDOSession cache. In this case it could implement is as
> you suggested.
No, they maintain their own "copies" of the CDOObject graph (remember that CDOObjects are really thin wrappers without
any model-specific data). But these CDOObjects share their CDORevisions (the model/branch/time specific data) through
the session (more exactly the revisionsmanager/cache of the session).

Cheers
/Eike

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


Previous Topic:Best practice for building eclipse data explorer view .
Next Topic:[CDO] Comparing object ids with OCL query
Goto Forum:
  


Current Time: Fri Mar 29 10:59:20 GMT 2024

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

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

Back to the top