Just thought that I would run this by you see what you think.
My repository root is PRMagmaRepository which contains a dictionary in its 'store' instance variable. This dictionary contains values of PRMagmaPesistency which references in instance var 'kernel' a PRKernel (the root of the current pier kernel data structure) and also a dictionary for historical data. [I dont use this history yet because there is a danger that it might indirectly reference the session]
Whenever the kernel data structure is edited this is managed by a mutex, (an instance var of PRKernel). I have arranged that whenever this mutex is used (as in critical: [] ) my class PRMagmaPersistency is able to wrap the critical block in a magmaSession commit: [].
doing: aCommand critical: aBlock
aCommand context session commit: [ self kernel critical: aBlock ].
At this point I thought that this was all that I would have to do in order to get things working, because I thought that once the commit was complete all other users of repository objects would be automatically be updated. Was that a valid/sensible assumpton?
Now I discovered that the structure that I am viewing in seaside is not necessarily the same one that is in the store. I thought that it would be, since I just put it into the repository. If it is not then that would explain why a commit: is having no effect because I am committing something that is not reachable from what Magma has as its root.
My next plan was to ensure that when seaside attempts to access a PRKernel instance at the beginning of a session it does it via the PRMagmaRepository instance which can ensure that it gets the one out of the repository.
getPersistedKernelFor: client
| persisted |
persisted := client session root store at: (self kernel name) ifAbsent: [ self inform: ('not found in database: ', self kernel name). self ].
^persisted kernel
I dont think that this approach is very fast, but it works. Is that to be expected?
Now it appears that if I manually change the database via my own little session. The current seaside session does not pick up the change.
If I restart the seaside session invoking the above code, then I get the new data ok.
So thats what I am doing so far... any comments?
Keith
Now it appears that if I manually change the database via my own little session. The current seaside session does not pick up the change.
So I figure that I need aMagmaSession abort somewhere to pick up the changes. And so I figured that I would do this on every web request.
responseForRequest: aRequest
magmaSession ifNotNil: [ magmaSession abort. ].
^super responseForRequest: aRequest
If I restart the seaside session invoking the above code, then I get the new data ok.
But this is a change that would effect all Magma Seaside applications, is this a desireable change? How do other apps do it?
Keith
___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
magma@lists.squeakfoundation.org