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