possible bug in VW glorp session pooling in Seaside

[Micael Alastor]

Hi

when I'm trying to perform big read request (thousands of objects)
from one seaside session and any read request from another seaside
session in same time I have a 99 percent chance to receive exception
"Read request made while another request is active." from this code:
------------------------------------------------------------------------------
SpNonBlockingSocketReadRequest class(SpAbstractSocketReadRequest
class)>>for:

for: anSpSocket
"^a SocketReadRequest of some kind
If anSpSocket already has an outstanding read request I throw an
exception, otherwise I create the new instance and return it."

anSpSocket activeReadRequest notNil
ifTrue:
[SpSocketError
raiseSignal: 'Read request made while another request is
active.'].
^(self concreteClassFor: anSpSocket) new for: anSpSocket
------------------------------------------------------------------------------
after this when I'm inspecting "anSpSocket activeReadRequest" it is
always nil. I'm afraid some code is not thread safe

[maarten...@stakepoint.com]

Hi,

I had a similar problem in a desktop app.

If you open a new database session for each seaside session, does that solve the problem ?

Regards,

 

@+Maarten,

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To post to this group, send email to glorp...@googlegroups.com.
To unsubscribe from this group, send email to glorp-group...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

[Micael Alastor]

At first glance: yes, it does.

[Alan Knight]

Yes, there's mutual exclusion in a single session to have only one query
executing at a time. Actually, it might be at the DatabaseAccessor
level. But if you're sharing below that level, then you won't have any
mutual exclusion and it won't be thread safe. And the underlying driver
isn't thread-safe. There's connection pooling stuff that has a pool of
connections and gives a session temporary access to one exclusively so
that's not an issue.

Micael Alastor wrote:
> At first glance: yes, it does.

> --
> You received this message because you are subscribed to the Google
> Groups "glorp-group" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/glorp-group/-/9VMd_GK5cl4J.

[Micael Alastor]

Hmmm may be I can't understand something, but connection pooling fails to work. I have no forks, no dirty hacks with connections.

Only standard seaside-glorp functionality.

Just one user in one session can't read from db at the same time when another user from another session == seaside-glorp is actually single user.

On Saturday, May 5, 2012 5:25:50 PM UTC+4, alan.knight wrote:

Yes, there's mutual exclusion in a single session to have only one query
executing at a time. Actually, it might be at the DatabaseAccessor
level. But if you're sharing below that level, then you won't have any
mutual exclusion and it won't be thread safe. And the underlying driver
isn't thread-safe. There's connection pooling stuff that has a pool of
connections and gives a session temporary access to one exclusively so
that's not an issue.


Micael Alastor wrote:
> At first glance: yes, it does.
> --
> You received this message because you are subscribed to the Google
> Groups "glorp-group" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/glorp-group/-/9VMd_GK5cl4J.
> To post to this group, send email to glorp...@googlegroups.com.
> To unsubscribe from this group, send email to

> glorp-group+unsubscribe@googlegroups.com.

[Micael Alastor]

I'm not sharing below that level =)

On Saturday, May 5, 2012 5:25:50 PM UTC+4, alan.knight wrote:

Yes, there's mutual exclusion in a single session to have only one query
executing at a time. Actually, it might be at the DatabaseAccessor
level. But if you're sharing below that level, then you won't have any
mutual exclusion and it won't be thread safe. And the underlying driver
isn't thread-safe. There's connection pooling stuff that has a pool of
connections and gives a session temporary access to one exclusively so
that's not an issue.


Micael Alastor wrote:
> At first glance: yes, it does.
> --
> You received this message because you are subscribed to the Google
> Groups "glorp-group" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/glorp-group/-/9VMd_GK5cl4J.
> To post to this group, send email to glorp...@googlegroups.com.
> To unsubscribe from this group, send email to

> glorp-group+unsubscribe@googlegroups.com.

[Micael Alastor]

Is it right to test my issue like this:

AosDatabaseTestCase(subclass of WAContextTest) >> testConcurrentDBAccess

| plan forkSession |

plan := self aosGiantPlan. // big complex data structure

self  session newGlorpSession inUnitOfWorkDo: [:session | session register: plan].

forkSession := self session newGlorpSession.

[forkSession readManyOf: AosLearningTreeElement] fork.

self session newGlorpSession readManyOf: AosLearningTreeElement

where 

aosGiantPlan consists of many AosLearningTreeElement and:

WATestSession >> newGlorpSession

| accessor databaseSession |

accessor := VWPoolingDatabaseAccessor forLogin: (AosConfigurator glorpLoginForTestsDB: 'test').

databaseSession := (GlorpSession new)

accessor: accessor;

system: (AosConfigurator descriptorSystem forPlatform: accessor platform);

dontUseModificationTracker;

yourself.

^databaseSession

So we have 2 independent glorpSessions (with their own processes) reading data via VWPoolingDatabaseAccessor instances with same (=) currentLogin.

If such test fails, can it say us something?

On Saturday, May 5, 2012 5:25:50 PM UTC+4, alan.knight wrote:

Yes, there's mutual exclusion in a single session to have only one query
executing at a time. Actually, it might be at the DatabaseAccessor
level. But if you're sharing below that level, then you won't have any
mutual exclusion and it won't be thread safe. And the underlying driver
isn't thread-safe. There's connection pooling stuff that has a pool of
connections and gives a session temporary access to one exclusively so
that's not an issue.


Micael Alastor wrote:
> At first glance: yes, it does.
> --
> You received this message because you are subscribed to the Google
> Groups "glorp-group" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/glorp-group/-/9VMd_GK5cl4J.
> To post to this group, send email to glorp...@googlegroups.com.
> To unsubscribe from this group, send email to

> glorp-group+unsubscribe@googlegroups.com.

[Micael Alastor]

UPD: nope... to solve the problem I must use new ConnectionPool for each seaside session.

[Alan Knight]

Well that's clearly not right. I'm not in a position to look into it at the moment, but the whole point of a connection pool is to be shareable between different sessions.

Micael Alastor wrote:

--

You received this message because you are subscribed to the Google Groups "glorp-group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/EzP2KLYb2ocJ.