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 -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
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,
-----Original Message----- Hi You received this message because you are subscribed to the Google Groups "glorp-group" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
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 [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
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 [hidden email]. > To unsubscribe from this group, send email to > [hidden email]. > For more options, visit this group at > http://groups.google.com/group/glorp-group?hl=en. -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
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 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/-/FCKCK6BWPEsJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
In reply to this post by Alan Knight
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-- 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/-/5-sLWR-btUQJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
In reply to this post by Alan Knight
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-- 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/-/wJQOemfRAh0J. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
In reply to this post by Micael Alastor
UPD: nope... to solve the problem I must use new ConnectionPool for each seaside session.
On Saturday, May 5, 2012 2:33:57 PM UTC+4, 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/-/EzP2KLYb2ocJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
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: UPD: nope... to solve the problem I must use new ConnectionPool for each seaside session.-- You received this message because you are subscribed to the Google Groups "glorp-group" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en. |
Free forum by Nabble | Edit this page |