magma pier

keith hodges keith.hodges at warwick.ac.uk
Fri Sep 8 14:15:43 UTC 2006


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






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20060908/ddd9dc61/attachment.htm


More information about the Magma mailing list