Craig R. McClanahan typed the following on 09:38 AM 12/26/2000 -0800
>> So far I'm looking to implement the FileStore class by cribbing code
>> from StandardManager's load() and unload() methods, to store session
>> data in individual files named with the session ID. I've also created a
>> class called PersistentManager which will use this store.
>>
>
>It might be possible to extract this code into a shared utility class if it is
>really reusable.
Sounds reasonable. Would it be useful in areas other than sessions,
e.g. for storing web application state?
>The general idea was that a Manager implementation interested in supporting
>persistence or swapping of sessions would choose a Store implementation (see
>below for config stuff), and would then call the load() and save() methods
>on it
>whenever the Manager's policies so dictated. This could be after every request
>(as Shai proposed), at startup/shutdown only (replacing the primitive mechanism
>used in StandardManager today), or dynamically for swapping or session moving.
What I'm thinking at the moment is to create PersistentManager, which will
be configurable to set the different policies you suggest, so users can tweak
it for their needs. The StandardManager could have its load() and unload()
code stripped, so it provides a bare-bones implementation.
A separate DistributedManager class could then be implemented, probably
sharing a fair amount of code with PersistentManager.
>* Create another level of nesting inside <Manager> called <Store>. This is
> probably better, because you can now configure the properties of the
> Store implementation using <Store> attributes.
This sounds like the best approach. I'll start digging around into how to
do this: if you can give me any pointers, good starting places, etc. I'd
appreciate it.
One issue: there are likely to be attributes specific to certain Store
implementations. Namely, FileStore needs to have a directory to
store its serialized sessions into, but this doesn't seem appropriate
for the Store interface. How should this work?
>> - The FileStore implementation I'm using needs to get access to the
>> Container.
>That makes sense to me -- in fact, I cannot imagine a Store implementation that
>would not need this. It should be added to the official Store interface so
>that
>all implementations have to support it.
A patch follows.
>If we use the second configuration approach, you can set up the configuration
>rules to call setManager() for you to establish this link, with an "set parent"
>rule, so that it happens for you automatically.
Cool!
Thanks,
Kief
---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938
fax +44 020 7460 4081
