[ANN] Magma 1.0r40

Igor Stasenko siguctua at gmail.com
Thu Sep 27 19:25:11 UTC 2007


I found code, which uses MagmaOidManager in two different processes. I
placed a check instead of Mutex in it, which throws error, if some
other process instead of one, which was first who accessed it tries to
deal with oids.

After running update, i found, that the only process, which accessing
oid manager except one, which running update is running by magma
itself:

See fork in MaObjectRepository>>flushCacheSoon.

After changing this method to:

flushCacheSoon
	self flushCritical:
			[ self commitCritical:
				[ self flushCache.
				applyProcess _ nil ] ]

there's no other processes who attempt to use oid manager from except
one, which runs update.

So, the conclusion is obvious: flush causing problems.

Cris, please check the #flushCritical: code. I think it should not run
inside a commit or parallel to commits if we want it to run it in
standalone process.
Otherwise magma disregards own rule which says that following is not allowed:
session commit: [
  [ some code ] fork
]

Also, i'm glad to note, that with changes in #flushCacheSoon, Florian
able to run own update without errors regardless using my dictionaries
or using stock classes.

But timing are different:
- out of the box magma: 18 minutes
- using my dictionaries: 8 minutes.

quite impressive for real world application isn't? :)

Cris, in attachment i placed the MagmaOidManager code, which checks
the process. Just for case, if you want to see it yourself.

-- 
Best regards,
Igor Stasenko AKA sig.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MagmaOidManager.st
Type: application/octet-stream
Size: 3877 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/magma/attachments/20070927/39bbcf54/MagmaOidManager.obj


More information about the Magma mailing list