Hi Johan -
I suggested trying to use a seperate instance of the ZODB, using MemoryStorage, so that all session objects would be in memory. This could then maybe be extended to support ZEO as well, but I haven't really dived into that yet.
Martijn's suggestion is probably the best (as usual), but it involves more effort (and thinking!) than the 10 lines script I wrote.
Ok. One (or more:) question(s).
- Why can't the session object rely on the ZODB memory cache. They are (for the most) fast deployed objects. Maybe even use _v_ objects (which would be automatically destroyed).
That is one way but your temporary data will be lost as soon as the object is deactivated (as you mentioned). With tmpStorage I can retrieve the info at any point, even days later.
- How does transactions slow down the process, and how are transactions connected to storage (in this situation)?
I am not sure what is the overhead of transactions but what I am trying to avoid is not transaction control (in principle I could make tmpStorage transaction aware), but as Martijn mentioned, to avoid new object creation.
Transaction support for sessions are one of the things you really want. I even been thinking about using private versions for sessions, for instance in a e-shop you would be able to customize your order directly in the OLAP-system but within a version. Not until you commit your transaction the changes gets propagated to the OLAP-system.
Agreed - Again, tmpStorage is a simple solution that is thread safe and fast. Those were my requirements at the time. A proper more general solution is the one mentioned by Martijn. Pavlos