Jerry Bell wrote:
Hi Keith,
Is #postProcessRequest: aRequest returned: aResponse meant to be used by a specialized subclass of WAMagma? I'm not sure how to use it.
#postProcessRequest:returned:
Is an unusual hook in that it is called after the seaside request has been serviced, and so should not slow down serving.
I havent really got any convincing use cases for this hook yet so it is not fully wired up for general use. Of course if you add your own specialised subclass of WAMagma then you can use it. Perhaps WAMagma should allow you to set a block which is evaluated by this hook.
I was using (WAMagma forApp: 'MyAppName') to access my database in the forked processes. Specifically, I have a singleton CCFApplication which I wanted to use to hold an database session to be shared by forked processes. However, I was still having problems unless I created a new database instance for each process. This morning I tried using this instead:
(WAMagmaSoloAuto forApp: 'MyAppName') - matching the session type I'm using for the rest of the application. This seems to be working much better. Perhaps I took WAMagma forApp: too literally?
Ah yes, if your seaside application is using WAMagmaSoloAuto, then it is assuming that seaside is the only user., and one magma session is serving all seaside sessions. Having other threads with their own (non-readonly) magma sessions may confuse WAMagmaSoloAuto.
Previously, I had switched from the deep copy to passing an ID to the forked process, and looking up that ID in the database session created via WAMagma for:. However, from looking at the WAMagmaControlPanel I believe that I'm using the same shared session from these forked processes as from the Seaside sessions. So I think it's likely that I could pass the actual objects around now.
Yes that would be ok.
Do you see any problems with this approach?
Note that WAMagmaSoloAuto serializes all database operations through a mutual exclusion semaphore. As long as you are aware of this and don't have a thread that accidentally hogs magma session you should be ok. Other non-solo strategies may be a better solution in the long run.
By the was all of these different strategies are a bit experimental, so if you find something not workin the way that it should, do say so.
Keith