modeling-cvs — Receives the syncmail-generated messages (CVS checkins messages)

[Modeling-cvs] ProjectModeling/Modeling EditingContext.py,1.20,1.21 CHANGES,1.75,1.76

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

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

Modified Files:
	EditingContext.py CHANGES 
Log Message:
Fixed EditingContext.objectsWithFetchSpecification(): when a nested EC
asks for objects, the result set now correctly includes objects that
are inserted in its parent (or grand-parent, etc.) and objects that
are marked as deleted in the parent are excluded.

See also: tests.test_EditingContext_ParentChild,
            test_10_child_gets_newly_inserted_objects() and
            test_11_child_doesnt_get_deleted_objects()



Index: EditingContext.py
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/EditingContext.py,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** EditingContext.py	12 Mar 2003 11:06:09 -0000	1.20
--- EditingContext.py	12 Mar 2003 15:45:54 -0000	1.21
***************
*** 1135,1140 ****
          insertObject()) but that are not saved yet.
  
!     Last, objects that are marked as deleted (cf. deleteObject()) in the
      EditingContext are not returned.
        
      If parameter 'anEditingContext' is omitted or 'None', it defaults to
--- 1135,1145 ----
          insertObject()) but that are not saved yet.
  
!     Objects that are marked as deleted (cf. deleteObject()) in the
      EditingContext are not returned.
+ 
+     When a nested EditingContext fetches objects, the result set will contain
+     the objects that are inserted in the parent (or the parent's parent,
+     etc.), and objects which are marked as deleted in parent will not be part
+     of the result set.
        
      If parameter 'anEditingContext' is omitted or 'None', it defaults to
***************
*** 1150,1157 ****
      fs=aFetchSpecification
      ec=anEditingContext
      
      objects=self.parentObjectStore().objectsWithFetchSpecification(fs, ec)
  
!     if anEditingContext is self:
        entitiesNames=[fs.entityName()]
        if fs.isDeep():
--- 1155,1163 ----
      fs=aFetchSpecification
      ec=anEditingContext
+     # +--> From this point we use 'ec' instead of 'anEditingContext'
      
      objects=self.parentObjectStore().objectsWithFetchSpecification(fs, ec)
  
!     if ec is self or ec.isaChildOf(self):
        entitiesNames=[fs.entityName()]
        if fs.isDeep():
***************
*** 1163,1175 ****
        for entityName in entitiesNames:
          # do not include deleted objects in the returned set of objects
!         ec_deletedObjects = ec.allDeletedObjects()
!         ec_insertedObjects = ec.allInsertedObjects()
!         for object in objects:
!           if object in ec_deletedObjects:
!             objects.remove(object)
          # now append inserted objects
          objs=[o for o in ec_insertedObjects if o.entityName()==entityName]
          if fs.qualifier():
            objs=filteredArrayWithQualifier(objs,fs.qualifier())
          objects.extend(objs)
  
--- 1169,1207 ----
        for entityName in entitiesNames:
          # do not include deleted objects in the returned set of objects
!         ec_insertedObjects = self.allInsertedObjects()
! 
!         if ec.isaChildOf(self):
! 
!           # If we're returning objects for a child's use, we remove the one
!           # that are marked for deletion in the parent (self) However, the
!           # deleted objects in self and the ones in the child-ec are distinct,
!           # but the GlobalIDs are the same and this is what we do here:
!           # compare the gIDs and remove the apropriate objects from the result
!           # set
!           ec_deletedGids=self._deletedObjects+self._pendingDeletedObjects
!           objects=[o for o in objects
!                    if ec.globalIDForObject(o) not in ec_deletedGids]
! 
!         else:
!           # We work for self, so we just remove the ones that are already
!           # marked as deleted
!           ec_deletedObjects = self.allDeletedObjects()
!           objects=[o for o in objects if o not in ec_deletedObjects]
!           
          # now append inserted objects
          objs=[o for o in ec_insertedObjects if o.entityName()==entityName]
          if fs.qualifier():
            objs=filteredArrayWithQualifier(objs,fs.qualifier())
+ 
+         # If we are returning objects for a child's use it is NOT POSSIBLE to
+         # return our (self's) objects, instead, we return a fault for the
+         # given object.
+         # Note that faultForGlobalID() is responsible for cloning inserted
+         # objects when they are requested by the nested EditingContext
+         if ec.isaChildOf(self):
+           fault_objs=[ec.faultForGlobalID(self.globalIDForObject(o), ec)
+                       for o in objs]
+           objs=fault_objs
+ 
          objects.extend(objs)
  

Index: CHANGES
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/CHANGES,v
retrieving revision 1.75
retrieving revision 1.76
diff -C2 -d -r1.75 -r1.76
*** CHANGES	10 Mar 2003 16:36:08 -0000	1.75
--- CHANGES	12 Mar 2003 15:45:55 -0000	1.76
***************
*** 8,18 ****
    --------------------------------------------------------
  
!   * EditingContext.saveChangesInEditingContext(): now locks 'self' before
!     proceeding, so that two nested \class{EditingContext} which have the same
!     parent and are managed by two different threads can concurrently save
!     their changes to their parent without explictly locking it.
!     (this is logical since a EC is supposed to perform any of its
!      operations safely in a multi-threaded environment --given that it's
!      not shared between threads, obviously)
  
    * Added Modeling.utilities.EditingContextSessioning
--- 8,29 ----
    --------------------------------------------------------
  
!   * EditingContext
! 
!     + saveChangesInEditingContext(): now locks 'self' before proceeding, so
!       that two nested \class{EditingContext} which have the same parent and
!       are managed by two different threads can concurrently save their changes
!       to their parent without explictly locking it.  (this is logical since a
!       EC is supposed to perform any of its operations safely in a
!       multi-threaded environment --given that it's not shared between threads,
!       obviously)
! 
!     + Fixed objectsWithFetchSpecification(): when a nested EC asks for
!       objects, the result set now correctly includes objects that are inserted
!       in its parent (or grand-parent, etc.) and objects that are marked as
!       deleted in the parent are excluded.
! 
!       See also: tests.test_EditingContext_ParentChild,
!                   test_10_child_gets_newly_inserted_objects() and
!                   test_11_child_doesnt_get_deleted_objects()
  
    * Added Modeling.utilities.EditingContextSessioning

[Modeling-cvs] ProjectModeling/Modeling EditingContext.py,1.19,1.20

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

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

Modified Files:
	EditingContext.py 
Log Message:
Fixed a stupid & buggy call including self in parameters

Index: EditingContext.py
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/EditingContext.py,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** EditingContext.py	10 Mar 2003 16:36:09 -0000	1.19
--- EditingContext.py	12 Mar 2003 11:06:09 -0000	1.20
***************
*** 1204,1208 ****
      self.lock()
      try:
!       self._savesChangesInEditingContext(self, anEditingContext)
      finally:
        self.unlock()
--- 1204,1208 ----
      self.lock()
      try:
!       self._savesChangesInEditingContext(anEditingContext)
      finally:
        self.unlock()

[Modeling-cvs] ProjectModeling/Modeling/doc/UserGuide ManipulatingGraphOfObjects.tex,1.6,1.7

[<ru...@us...>]

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

Modified Files:
	ManipulatingGraphOfObjects.tex 
Log Message:
typos: Destruction process of an EditingContext

Index: ManipulatingGraphOfObjects.tex
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide/ManipulatingGraphOfObjects.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** ManipulatingGraphOfObjects.tex	10 Mar 2003 10:17:45 -0000	1.6
--- ManipulatingGraphOfObjects.tex	11 Mar 2003 07:53:03 -0000	1.7
***************
*** 364,370 ****
  \subsection{Finalizing an \class{EditingContext}: breaking reference cycles\label{ec-finalization}}
    When an \class{EditingContext} is about to be deleted, its 
!   \method{dispose()} method gets called. What follows then is a two-step procedure:
  
- Each object registered within the EC is then:
  \begin{enumerate}
  
--- 364,371 ----
  \subsection{Finalizing an \class{EditingContext}: breaking reference cycles\label{ec-finalization}}
    When an \class{EditingContext} is about to be deleted, its 
!   \method{dispose()} method gets called. 
!   This is followed with a two-step procedure, acting on each object registered 
!   within the \class{EditingContext}:
  
  \begin{enumerate}
  
***************
*** 383,387 ****
  \begin{itemize}
  \item{}
! If it is true, then the object receives the message
  \method{clearProperties}, defined in \class{DatabaseObject}, which empties
  its \member{__dict__} -- this is called {\em invalidating the object}.
--- 384,388 ----
  \begin{itemize}
  \item{}
! If true, then the object receives the message
  \method{clearProperties}, defined in \class{DatabaseObject}, which empties
  its \member{__dict__} -- this is called {\em invalidating the object}.
***************
*** 425,429 ****
  
  \item[\member{EditingContext.invalidatesObjectsWhenFinalized}] is a class
! attribute that controls the global behaviour for all \class{EditingContext}
  {\em except those which were specifically configured} (see below). If
  set to true, all existing and future EditingContexts will invalidate their
--- 426,430 ----
  
  \item[\member{EditingContext.invalidatesObjectsWhenFinalized}] is a class
! attribute that controls the global behaviour for all \class{EditingContext} instances
  {\em except those which were specifically configured} (see below). If
  set to true, all existing and future EditingContexts will invalidate their
***************
*** 431,435 ****
  
  \item[\method{EditingContext.setInvalidatesObjectsWhenFinalized()}] controls
! whether a specific \class{EditingContext} invalidates its objects when it's
  been disposed. Note that this setting supersedes the previous one.
  
--- 432,436 ----
  
  \item[\method{EditingContext.setInvalidatesObjectsWhenFinalized()}] controls
! whether a specific \class{EditingContext} instance invalidates its objects when it's
  been disposed. Note that this setting supersedes the previous one.
  

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

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

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

Modified Files:
	FrameworkTypicalUsage.tex 
Log Message:
Wrote subsection "Sessioning" in section "Application servers"

Index: FrameworkTypicalUsage.tex
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide/FrameworkTypicalUsage.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** FrameworkTypicalUsage.tex	10 Mar 2003 19:12:11 -0000	1.2
--- FrameworkTypicalUsage.tex	10 Mar 2003 21:42:04 -0000	1.3
***************
*** 13,16 ****
--- 13,19 ----
  take different approaches. We'll see how this can be done, either in a
  pure-python application or within application servers like Zope or others.
+ We suggest that you read the whole chapter, whatever your specific needs are:
+ it contains important informations explaining how the framework reacts and how
+ it can be used in standard situations.
  
  %%
***************
*** 133,139 ****
  
  
! 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?
  
--- 136,142 ----
  
  
! 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?
  
***************
*** 146,154 ****
  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}
  
--- 149,157 ----
  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 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!
  \end{notice}
  
***************
*** 157,169 ****
  
  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}}
  
! TBD
  
  \section{Others\label{framework-integration-others}}
--- 160,196 ----
  
  The second approach involves a per-session creation mechanism for
! \class{EditingContext}s.
! 
! 
! The framework provides the module \module{utilities.EditingContextSessioning}
! for such situations. This module acts as central repository to which a
! sessioning mechanism can be bound for creating, accessing and destroying an
! \class{EditingContext} as sessions come up and expire.
! The module documentation gives full details about its methods and how they can
! be used.
  
  
  \paragraph*{Known problem:}
! By definition, such a configuration isolates the changes different users make
! {\em until} they are committed. The problem here is that even {\em after} a
! user has committed changes, the other users that are already connected and
! whose session already got an \class{EditingContext} {\bf will not see} the
! changes made to objects previously fetched -- new users connecting afterwards
! will see the changes, though, as will current users who did not fetch the
! updated objects before they were committed.
! 
! \begin{quote}
! This is due to a feature missing in the framework, where changes to an
! EditingContext are not broadcasted to others. This is a TODO, highly
! prioritary, which is planned to be solved in the release after 0.9 (ETA: end
! of march 2003).
! \end{quote}
! 
! There is currently no satisfying solution for this problem.
! 
  
  \section{Zope\label{framework-integration-zope}}
  
! \module{ZEditingContextSessioning}
  
  \section{Others\label{framework-integration-others}}

[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}}

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

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

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

Added Files:
	FrameworkTypicalUsage.tex 
Log Message:
Added: doc/UserGuide/FrameworkTypicalUsage (to be continued)

--- NEW FILE: FrameworkTypicalUsage.tex ---
%%
\chapter{Integration in an application\label{framework-integration-hints}}

When writing an application using the framework, you normally do not care
about any of its component except \class{EditingContext}s.

An \class{EditingContext} is basically the place where your object lives,
i.e. where they are inserted, fetched, deleted, or updated. This is an
important object, like a container, holding your graph of objects as it gets
changed, until the point where these changes are saved as a whole.

However, depending on the kind of applications you are developing, you will
take different approaches. We'll see how this can be done, either in a
pure-python application or within application servers like Zope or others.

%%
\section{Pure python applications\label{framework-integration-pure-python}}

For a standard python application, you'll probably do not need more than one
\class{EditingContext}, containing all your objects. Typically, you will
delegate the building and servicing for that application-wide
\class{EditingContext} to some central manager all your
objects/widgets/whatever we have access to.

Additionally, you'll maybe need from time to time to create a child
\class{EditingContext}, for example if you need to make some changes and
processing in a pop-up window and want to propose a 'Cancel' button at any
point of the process. See chapter~\ref{nested-editing-context} for details.

\paragraph*{Python ''batches'':} if you're designing python scripts
fetching and manipulating a lot of objects, please also read
section~\ref{ec-discard-changes} which enlightens valuable details about
finalization of an \class{EditingContext}.


%%
\section{Instructions of use in a multi-threaded environment\label{framework-integration-MT-considerations}}

The framework itself is designed to work in a multi-threaded environment, and
it makes sure that critical sections accessing shared variables are correctly
handled (such as when the module \module{Database} provides or updates the
globally cached database snapshots).

However, the \class{EditingContext} itself is not MT-safe by default. If your
application requires that an \class{EditingContext} is concurrently accessed
by different threads, you have to make sure that you lock it before use (e.g.,
before saving changes) ; methods \method{lock()} and
\method{unlock()} are provided for that purpose. Typical usage follows:
\begin{verbatim}
try:
  ec.lock()
  ec.saveChanges()
finally:
  ec.unlock()
\end{verbatim}

\begin{notice}[warning]
Locking an \class{EditingContext} does {\bf \sc not} lock the objects it
contains. If you want e.g. to be able to concurrently access \& update the
objects, you can take different approaches. For example, you might decide to
use the \class{EditingContext} lock as a global locking mechanism, or you'll
design your own locking scheme for your objects.
\end{notice}

Last, two nested \class{EditingContext} which have the same parent and are
managed by two different threads can concurrently save their changes to their
parent without explictly locking it --this is managed automatically. This is
worth noticing, even if this is logical since the framework is supposed to
ensure that any operations made on an \class{EditingContext} is safe in a
multi-threaded environment (given that the \class{EditingContext} is not
shared between threads, obviously).

%%
\section{Application servers, Zope\label{framework-integration-applications-servers}}

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}}

TBD

\section{Others\label{framework-integration-others}}

- sessioning 

- cgi? --> do not think so (initialization process is probably too heavy)

[Modeling-cvs] ProjectModeling/Modeling/doc UserGuide.tex,1.16,1.17

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

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

Modified Files:
	UserGuide.tex 
Log Message:
Added: doc/UserGuide/FrameworkTypicalUsage (to be continued)

Index: UserGuide.tex
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** UserGuide.tex	2 Mar 2003 18:55:04 -0000	1.16
--- UserGuide.tex	10 Mar 2003 17:26:49 -0000	1.17
***************
*** 45,48 ****
--- 45,49 ----
  \input{UserGuide/ManipulatingGraphOfObjects}
  \input{UserGuide/NestedEditingContext}
+ \input{UserGuide/FrameworkTypicalUsage}
  
  \appendix

[Modeling-cvs] ProjectModeling/Modeling/doc/UserGuide EnvironmentVariables.tex,1.3,1.4

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

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

Modified Files:
	EnvironmentVariables.tex 
Log Message:
Fixed: use cmd. newline instead of double-backslashes to make a newline in a tabular environment

Index: EnvironmentVariables.tex
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide/EnvironmentVariables.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** EnvironmentVariables.tex	7 Mar 2003 18:00:27 -0000	1.3
--- EnvironmentVariables.tex	10 Mar 2003 17:02:50 -0000	1.4
***************
*** 19,24 ****
  \code{ec.objectsCountWithFetchSpecification}, \code{ec.saveChanges()}.
  When this environment variable is set to any true value, the same database
! connection is re-used for subsequent requests.\\
! ~\\
  {\bf Important:} If you are running the framework in a multi-threaded
  environment (in Zope e.g.) you are strongly advised {\bf against} setting this
--- 19,24 ----
  \code{ec.objectsCountWithFetchSpecification}, \code{ec.saveChanges()}.
  When this environment variable is set to any true value, the same database
! connection is re-used for subsequent requests.\newline
! ~\newline
  {\bf Important:} If you are running the framework in a multi-threaded
  environment (in Zope e.g.) you are strongly advised {\bf against} setting this

[Modeling-cvs] ProjectModeling/Modeling CHANGES,1.74,1.75 EditingContext.py,1.18,1.19

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

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

Modified Files:
	CHANGES EditingContext.py 
Log Message:
EditingContext.saveChangesInEditingContext(): now locks 'self' before
proceeding, so that two nested \class{EditingContext} which have the
same parent and are managed by two different threads can concurrently
save their changes to their parent without explictly locking it.
(this is logical since a EC is supposed to perform any of its
operations safely in a multi-threaded environment --given that it's
not shared between threads, obviously)


Index: CHANGES
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/CHANGES,v
retrieving revision 1.74
retrieving revision 1.75
diff -C2 -d -r1.74 -r1.75
*** CHANGES	10 Mar 2003 13:28:49 -0000	1.74
--- CHANGES	10 Mar 2003 16:36:08 -0000	1.75
***************
*** 8,13 ****
    --------------------------------------------------------
  
    * Added Modeling.utilities.EditingContextSessioning
!  
    * Changed _invalidatesObjectsWhenFinalized to
               invalidatesObjectsWhenFinalized,
--- 8,21 ----
    --------------------------------------------------------
  
+   * EditingContext.saveChangesInEditingContext(): now locks 'self' before
+     proceeding, so that two nested \class{EditingContext} which have the same
+     parent and are managed by two different threads can concurrently save
+     their changes to their parent without explictly locking it.
+     (this is logical since a EC is supposed to perform any of its
+      operations safely in a multi-threaded environment --given that it's
+      not shared between threads, obviously)
+ 
    * Added Modeling.utilities.EditingContextSessioning
! 
    * Changed _invalidatesObjectsWhenFinalized to
               invalidatesObjectsWhenFinalized,

Index: EditingContext.py
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/EditingContext.py,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -d -r1.18 -r1.19
*** EditingContext.py	8 Mar 2003 16:23:15 -0000	1.18
--- EditingContext.py	10 Mar 2003 16:36:09 -0000	1.19
***************
*** 1189,1193 ****
      changes.
  
- 
      Exceptions that can be raised:
  
--- 1189,1192 ----
***************
*** 1196,1200 ****
--- 1195,1215 ----
        -
        
+     Note: this method also automatically locks 'self' before actually
+           saving the changes ; this makes it possible for two children of a
+           single EC to safely save their changes in two different threads
+           without having to worry about explicitly locking the parent EC.
+     
      See also: saveChanges(), processRecentChanges()
+     """
+     self.lock()
+     try:
+       self._savesChangesInEditingContext(self, anEditingContext)
+     finally:
+       self.unlock()
+       
+   def _savesChangesInEditingContext(self, anEditingContext):
+     """
+     Private method called by saveChangesInEditingContext() after self has
+     been locked.
      """
      if anEditingContext.parentObjectStore()!=self:

[Modeling-cvs] ProjectModeling/Modeling CHANGES,1.73,1.74

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

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

Modified Files:
	CHANGES 
Log Message:
Added a whitespace -- testing the fwdg of checkin msg. to modeling-cvs

Index: CHANGES
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/CHANGES,v
retrieving revision 1.73
retrieving revision 1.74
diff -C2 -d -r1.73 -r1.74
*** CHANGES	8 Mar 2003 16:26:26 -0000	1.73
--- CHANGES	10 Mar 2003 13:28:49 -0000	1.74
***************
*** 8,11 ****
--- 8,13 ----
    --------------------------------------------------------
  
+   * Added Modeling.utilities.EditingContextSessioning
+  
    * Changed _invalidatesObjectsWhenFinalized to
               invalidatesObjectsWhenFinalized,