WAMagmaSharedSession
Locked
 
|
In the latest Magma seaside package I have added an experimental session
that only uses one session per repository. This makes sense (I think) for pier because pier manages its own model locking on its model. Performance is much better too Keith ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Lukas,
I would like to change PRKernel instances to be managed by a KeyedSet. I am seeking prior approval before submitting the work. I am looking forward to a time when there may be many many more pier kernels in one system, and the pier application serves them all (or a nominated subset) rather than just one. Lookup performance will be better, especially with the Magma-Pier changes that I made to make the application preference a String #kernelName rather than a PRKernel instance #kernel. Also error messages become consistent, e.g. creating a kernel with an already existing name. your thoughts? Keith ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
2006/9/9, Keith Hodges <[hidden email]>:
> Lukas, > > I would like to change PRKernel instances to be managed by a KeyedSet. I > am seeking prior approval before submitting the work. > > I am looking forward to a time when there may be many many more pier > kernels in one system, and the pier application serves them all (or a > nominated subset) rather than just one. > > Lookup performance will be better, especially with the Magma-Pier > changes that I made to make the application preference a String > #kernelName rather than a PRKernel instance #kernel. > > Also error messages become consistent, e.g. creating a kernel with an > already existing name. > > your thoughts? I dislike KeyedSets because they don't work well together with persistence in general. But if we use a symbol instead of a block (Magritte adds #value: to Symbol) we should be able to work around this. Philippe _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
KeyedSets do not have to use a block, if the items respond to #key. Its
a bit of a hack but in this case all it needs is for PRKernel to implement #key. As for persistence not working with it, surely that has to be a limitation of a particular persistence solution. As far as Magma is concerned I dont think it is necessary to persist "PRKernel instances". I agree that it would be much nicer if Magma did support KeyedSets fully which it doesnt. I would happily put a KeyedSet in as my repository root. (I already tried it). Keith > I dislike KeyedSets because they don't work well together with > persistence in general. But if we use a symbol instead of a block > (Magritte adds #value: to Symbol) we should be able to work around > this. > > Philippe > > ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Philippe Marschall
In trying to implement MagmaPersistency it turns out that the fact that
PRContext holds a local cache to the current session may be a bit of a pain. Not only may there be a lot more stuff accidentally persisted through this reference, there may actually be objects that magma gurus say 'don't persist these if you know what is good for you'. I cant see that this cache is widely used, so I wondered if anyone would object if it was removed i.e. make this method lookup the current session the hard but not all that slow way (about 100 microseconds, on my oldish 700Mhz machine) PRContext>>session ^ WACurrentSession value any thoughts/opinions? Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
> The problem that I have is that pier saves its history by saving its
> instances of PRContext', namely the context of the model changing > command being performed. This context happens to have a local cache > in > it's properties the seaside session ('to avoid unneccessary > lookups'), > which if it is WAMagmaSession has a magmaSession instance var. > > Now I could attempt to clear this cached value out before persistence > takes place, but I see no guarantees that some other bit of code may > reference the session and repopulate the cached value while I am not > looking. Hi Keith, could the MagmaSessions #location help here? The #location gives you a MagmaLocation which was intended for this purpose; it can be serialized/materialized, and let you get a #newSession any time. You could clear the cached value before persistence and change its getter to lazy initialize it from the location..? - Chris --- Keith Hodges <[hidden email]> wrote: > In trying to implement MagmaPersistency it turns out that the fact > that > PRContext holds a local cache to the current session may be a bit of > a > pain. Not only may there be a lot more stuff accidentally persisted > through this reference, there may actually be objects that magma > gurus > say 'don't persist these if you know what is good for you'. > > I cant see that this cache is widely used, so I wondered if anyone > would > object if it was removed > > i.e. make this method lookup the current session the hard but not all > that slow way (about 100 microseconds, on my oldish 700Mhz machine) > > PRContext>>session > > ^ WACurrentSession value > > any thoughts/opinions? > > Keith > > > > > ___________________________________________________________ > The all-new Yahoo! Mail goes wherever you go - free your email > address from your Internet provider. > http://uk.docs.yahoo.com/nowyoucan.html > _______________________________________________ > Magma mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by keith1y
> In trying to implement MagmaPersistency it turns out that the fact
> that > PRContext holds a local cache to the current session may be a bit of a > pain. Not only may there be a lot more stuff accidentally persisted > through this reference, there may actually be objects that magma gurus > say 'don't persist these if you know what is good for you'. What kind of cache? There is a reference to the kernel. To the currently browsed structure and the currently executed command. Moreover there is a time-stamp and an enumerator object. Ideally descriptions on the class-side should tell you what fields have to be persistent. > I cant see that this cache is widely used, so I wondered if anyone > would > object if it was removed Is it something you added yourself? I am lost :-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Lukas Renggli wrote:
>> In trying to implement MagmaPersistency it turns out that the fact >> that >> PRContext holds a local cache to the current session may be a bit of a >> pain. Not only may there be a lot more stuff accidentally persisted >> through this reference, there may actually be objects that magma gurus >> say 'don't persist these if you know what is good for you'. >> > > What kind of cache? > > "Answer the cached seaside session, this is a short-cut to avoid to unnecessary lookups." ^ self propertyAt: #session ifAbsentPut: [ WACurrentSession value ] This kind of cache! Keith ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: Re: PRKernel instances
|
|
In reply to this post by keith1y
2006/9/11, Keith Hodges <[hidden email]>:
> KeyedSets do not have to use a block, if the items respond to #key. Its > a bit of a hack but in this case all it needs is for PRKernel to > implement #key. > > As for persistence not working with it, surely that has to be a > limitation of a particular persistence solution. OmniBase, (Smart) ReferenceStream, Goods, PostgreS all do not support blocks. Magma does not really and fully support blocks. Philippe _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by keith1y
>>> In trying to implement MagmaPersistency it turns out that the fact
>>> that >>> PRContext holds a local cache to the current session may be a bit >>> of a >>> pain. Not only may there be a lot more stuff accidentally persisted >>> through this reference, there may actually be objects that magma >>> gurus >>> say 'don't persist these if you know what is good for you'. >>> >> >> What kind of cache? >> >> > PRContext>>session > "Answer the cached seaside session, this is a short-cut to > avoid to > unnecessary lookups." > > ^ self propertyAt: #session ifAbsentPut: [ WACurrentSession > value ] > > This kind of cache! I see, this is not really useful if you use a persistency mechanism that dumps out the whole objects. The idea was that Pier knows using the description what parts of the objects to serialize, something that is probably not easily controllable with a framework using the Smalltalk reach-ability to serialize objects. So I would suggest that you remove this cache. What's the trouble with MAProxyObject instances? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Latest release of image available at ftp.seasidehosting.st
Username: preloaded password: squeak Sqk3.8f-smp0.9.image (and changes) This release supports the logging of changes. I do this by copying the useful parts of a PRContext before putting them into the repository and when taking them out of the repository copying them again before using them. For now this seems to work ok. Keith ---------------- Welcome to the Seaside Magma Pier preloaded image. Please send your comments to the magma or pier mailing lists. ---------------------------------------------------------- This release smp 0.9 11thSept2006 First release fully supporting Magma-Pier integration with history and changes logs. ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
> I see, this is not really useful if you use a persistency mechanism > that dumps out the whole objects. The idea was that Pier knows using > Indeed. > the description what parts of the objects to serialize, something > that is probably not easily controllable with a framework using the > Smalltalk reach-ability to serialize objects. > > So I would suggest that you remove this cache. > > It seems that most of the properties in PRContext are not very useful when persisted. My current approach explicitly copies the parts of the object that I wish to persist, and so now it is not absolutely necessary to remove this cache. I have removed Pier-Magma's use of this cache, and so it remains to see who else actually uses it. > What's the trouble with MAProxyObject instances? > > I am not really sure of the ins and outs of this. I think that Magma was attempting to serialise part of the PRContext structure at the time. The proxy was to an Array of Commands, containing 8 items. Magma was looping through them to serialise them and asked for maInstSize which returned 9 rather than 8, owing to the fact that ProtoObject (i.e MAProxyObject) returns maInstSize as (^self class instSize + self basicSize ) differently to Object. I.e. the call to maInstSize is not being proxied. A fix would be to add an explicit maInstSize to MAProxyObject. I suspect that it would be worth setting up a test case for this one and to work out just what the desired behaviour actually is. Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |