[Modeling-cvs] ProjectModeling/Modeling/doc/UserGuide FrameworkTypicalUsage.tex,1.1,1.2

[<sbi...@us...>]

Update of /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide
In directory sc8-pr-cvs1:/tmp/cvs-serv20343/UserGuide

Modified Files:
	FrameworkTypicalUsage.tex 
Log Message:
Enhanced section "Sharing an EditingContext between session"

Index: FrameworkTypicalUsage.tex
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide/FrameworkTypicalUsage.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** FrameworkTypicalUsage.tex	10 Mar 2003 17:26:50 -0000	1.1
--- FrameworkTypicalUsage.tex	10 Mar 2003 19:12:11 -0000	1.2
***************
*** 75,123 ****
  
  For an application run by an application server, different approaches are
! possible:
  
  \begin{enumerate}
  
  \item{}
! you can choose to have the same configuration as in a standalone python app.,
! i.e. an application-wide \class{EditingContext}. In this case you will
! occasionally create a specific \class{EditingContext} on which the changes
! will be made (you'll probably want to use a child
! \class{EditingContext} in this case, see chapter~\ref{nested-editing-context}.
! The reason for not using the the app.-wide EC is obviously that you do not
! want your users to see the changes made by others until they are committed to
! the database.
  
  \item{}
! You can also choose to assign a different \class{EditingContext} bound to each
! (http-)session.
  
  \end{enumerate}
  
! \subsection{Sharing an \class{EditingContext} between session\label{framework-integration-shared-ec}}
! The first solution requires that you take all appropriate actions to ensure
! that your application is MT-safe, as described in paragraphs above. Then, you
! must keep in mind that the shared \class{EditingContext} will receive all the
! objects that can be possibly loaded by the sessions coming up. If your
! database is quite big, you will probably end up with all your objects being
! loaded in the shared \class{EditingContext} after some hours or days
! (depending on the number of hits your app. receives, the number of objects
! that a request can load, etc.).
  
  
! Moreover, you do not have any mean to distinguish between the objects loaded
! by session $S_1$ and objects loaded by session $S_2$ ; as a consequence you
! cannot clean up the shared \class{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 \class{EditingContext} and create a brand new one.
  
- %% Note: it is in situations like this where it would be nice to add the
- %% following feature to an EC: like in ZODB/Zope, have a 'maximum number of
- %% cached objects' trigger the invalidation of objects when needed
  
  \subsection{Sessioning\label{framework-integration-sessioning-ec}}
  
! TBD
  
  \section{Zope\label{framework-integration-zope}}
--- 75,165 ----
  
  For an application run by an application server, different approaches are
! possible. All of them requires at some point that you have a sessioning
! machinery at hand. It should not be a problem since most, if not all
! application servers offer such a mechanism.
  
  \begin{enumerate}
  
  \item{}
! You can choose to have the same configuration as in a standalone python app.,
! i.e. an application-wide \class{EditingContext}.
  
  \item{}
! Or you can also decide to bind a different \class{EditingContext} to each
! session.
  
  \end{enumerate}
  
! Each option has its counter-part ; some are inherently bound to what they are,
! some are due to specific features not being implemented yet. Let's look at
! the details.
  
+ %
+ \subsection{Sharing an \class{EditingContext} between sessions\label{framework-integration-shared-ec}}
  
! The first solution consists in having a single shared \class{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 \class{EditingContext} on which the changes
! will be made -- we recommend that you use a child
! \class{EditingContext} in this case, see chapter~\ref{nested-editing-context}.
! For the same reason, the \class{EditingContext} used for registering and
! saving the modifications should not be shared by
! 
! 
! Then, you must keep in mind that the shared \class{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 \class{EditingContext} after
! some hours or days (depending on the number of hits your app. 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 mean to distinguish between the
+ objects loaded by session $S_1$ and objects loaded by session $S_2$ ; as a
+ consequence you cannot clean up the shared \class{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 \class{EditingContext} and create a brand new one.
+ 
+ 
+ For these reasons, we do not recommend that way -- 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?
+ 
+ 
+ \begin{notice}
+ At some point in the future it is possible that we change our mind and support
+ such a configuration. This is related to a feature which is not implemented
+ yet ; it is possible that we support in the future a special attribute for you
+ to specify how many (unchanged) objects you want an \class{EditingContext} to
+ contain at most. Then, when the maximum number of objects is reached, it would
+ be possible to automatically clean the \class{EditingContext} (the oldest
+ object would be re-faulted/invalidated, or ''ghostified'' in {\sc zodb}
+ jargon).
+ 
+ There is no {\sc eta} for this feature however, it is just a {\sc todo}
+ item. If you think you need the feature, please go ahead and let us know!
+ \end{notice}
+ 
+ %
  \subsection{Sessioning\label{framework-integration-sessioning-ec}}
  
! The second approach involves a per-session creation mechanism for
! \class{EditingContext}s. 
! 
! 
! \paragraph*{Known problem:}
! Inter-EC notifications of changes is not handled yet
  
  \section{Zope\label{framework-integration-zope}}