6.3.1 Sharing an EditingContext between sessions

The first solution consists in having a single shared EditingContext in your application.

It obviously requires that you take all appropriate measures to ensure that your application is MT-safe, as described in the previous section.

What about making changes? Obviously you do not want your users to see the changes made by others until they are committed to the database. Thus, you'll occasionally create a specific EditingContext on which the changes will be made - we recommend that you use a child EditingContext in this case, see chapter 5. For the same reason, the EditingContext used for registering and saving the modifications should not be shared by different users.

Then, you must keep in mind that the shared EditingContext will receive all the objects that can be possibly loaded by the sessions coming up. The main problem with such an approach is that you will probably end up with all your objects being loaded in the shared EditingContext after some hours or days (depending on the number of hits your application receives, the number of objects that a request can load, etc.). If your database is quite big and/or if it quickly grows, your application is likely to end with exhausting the available memory.

What happens here is you do not have any means to distinguish between the objects loaded by session

and objects loaded by session

; as a consequence you cannot clean up the shared EditingContext when a session is expired and destroyed. The only thing you can do for clean-up is to detect that no more sessions are available: at this point, you would probably drop the existing EditingContext and create a brand new one.

For these reasons, we do not recommend this solution - except maybe in special cases where the database is a small one, but even then, why would you use a database if you can't count on your application to scale when the db is growing?

Note: At some point in the future, with the implementation of the following feature described below, this negative recommendation may change: We may support a special attribute for you to specify the maximum number of (unchanged) objects you want an EditingContext to contain. Then, when the maximum number of objects is reached, it would be possible to automatically clean the EditingContext (the oldest object would be re-faulted/invalidated, or ''ghostified'' in ZODB jargon). There is no ETA for this feature however, it is just a TODO item. If you think you need the feature, please go ahead and let us know!