Dear Chris,
I discovered that opening a session, before a prior session had completed being opened resulted in two open repositorycontrollers. i.e. openedOn: was returning nil for a controller that was already in the process of being opened.
This also results in clients being given the same id for multiple sessions.
I solved this by putting a critical block around our #newSession code.
Keith
Hi, thanks for reporting it. I'd like to incorporate your/a fix into the pending release.
Can you help me with some of the details? I gather you are talking about two Smalltalk Processes each doing:
MagmaSession openLocal: 'my repository'
at the same time, both leading them through MagmaRepositoryController>>#openedOn:, where, since the first one didn't finish yet, the second one also tries to #open: a new one. Yeah, that's not good.
Magma objects themselves (read: on the instance-side) do guard their own internals from access between multiple processes. But this problem is occurring on the class-side, where there is no Semaphore/Monitor guard available. Part of me wants to say this falls into the responsibility of the end-user app. It is creating instances of Magma objects as its own internals, so it should probably maintain responsibility for guarding access to them if it uses multiple processes.
I merged Magma server-kph.206, thanks for that, but I did not see any code addressing this issue. So what guard did you use to protect the opening of the sessions? Did you add a class-var?
Regards, Chris
On 6/25/07, Keith Hodges keith_hodges@yahoo.co.uk wrote:
Dear Chris,
I discovered that opening a session, before a prior session had completed being opened resulted in two open repositorycontrollers. i.e. openedOn: was returning nil for a controller that was already in the process of being opened.
This also results in clients being given the same id for multiple sessions.
I solved this by putting a critical block around our #newSession code.
Keith _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi Chris!
"Chris Muller" asqueaker@gmail.com wrote: [SNIP]
I merged Magma server-kph.206, thanks for that, but I did not see any code addressing this issue. So what guard did you use to protect the opening of the sessions? Did you add a class-var?
No, we have a class called Q2MagmaSessionPool in Gjallar which in turn is a derivative from Cees' code in Kilauea - and in there Keith added a critical: around the code that allocates a new session to serialize the allocations.
regards, Göran
magma@lists.squeakfoundation.org