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