Re: Stateless server (GWT)

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Aug 27 2008 - 08:52:14 EDT

  • Next message: Scott Anderson: "RE: Making columnOriginal and columnNew public"

    Sorry, I meant 3.0M4.

    When getting a new DataContext on every request, you bypass one level
    of caching, but in your situation this may actually be what you want.

    Andrus

    On Aug 27, 2008, at 3:43 PM, Krzysztof Janowicz wrote:

    > Hi Andrus,
    >
    > thanks for the reply. Isn't creating a new context per request very
    > ineffective (see
    > http://cayenne.apache.org/doc/obtaining-datacontext.html)? Cayenne
    > 3.0M5
    > is the version from SVN (or a nightly build), right? I will try this
    > one, thanks again.
    >
    > Krzysztof
    >
    >
    > Andrus Adamchik schrieb:
    >> Hi Krzysztof,
    >>
    >> You can switch to Cayenne 3.0M5. It uses weak references and will
    >> prevent objects in the ObjectStore from accumulating. Or throw away
    >> the context at the end of the request or after N requests.
    >>
    >> Andrus
    >>
    >> On Aug 27, 2008, at 2:23 PM, Krzysztof Janowicz wrote:
    >>
    >>> Hi,
    >>>
    >>> I am playing around with GWT, trying to implement a stateful
    >>> client with
    >>> a stateless server (IMO this is the paradigm shift proposed by the
    >>> google guys). While this is a very promising solution for massive
    >>> Web
    >>> 2.0 ajax applications, I am running into some trouble handling
    >>> this with
    >>> cayenne (2.0.4).
    >>>
    >>> Most of the application logic is handled by the GWT client. The
    >>> servlet
    >>> (GWT RPCService) is only used if the users change their settings
    >>> or have
    >>> to interact with each other. As there will be many users I don't
    >>> want to
    >>> have a session and associated datacontext per user. This would be
    >>> very
    >>> ineffective, since communication between client and server is
    >>> reduced to
    >>> a minimum. In addition, the datacontext stores objects in the
    >>> objectstore to manage their states, this is not necessary in a
    >>> stateless
    >>> server scenario. Moreover, there are several isolated RPC services
    >>> the
    >>> users are interacting with.
    >>>
    >>> Hence, I decided to bind the context to a thread (see
    >>> http://cayenne.apache.org/doc20/obtaining-datacontext.html). Each
    >>> servlet handles a couple of threads automatically (in my case
    >>> tomcat)
    >>> and each thread has an own datacontext. This seems to be a nice
    >>> solution
    >>> as I don't face and tread-safety problems and don't need to care
    >>> about
    >>> sessions.
    >>>
    >>> The first thing when executing a method within a RPCService is to
    >>> call a
    >>> getcontext() method which gets the datacontext bounded to the thread
    >>> (DataContext.getThreadDataContext()) or creates one
    >>> (DataContext
    >>> .bindThreadDataContext(DataContext.createDataContext(false)))
    >>>
    >>> if this is the first time this thread is executed by the servlet
    >>> container. My only concern so far is the objectstore of the
    >>> datacontext
    >>> which keeps collecting objects. I set
    >>> cayenne.DataRowStore.snapshot.size
    >>> to 1 but this only affects the DataRowStore. I tried to use
    >>> context.getObjectStore().startTrackingNewObjects() and then
    >>> context.getObjectStore().unregisterNewObjects() every time i get the
    >>> context from the thread but this does not solve my problem. IMO i
    >>> don't
    >>> need to track any objects in the objectStore. If a client calls a
    >>> RPCService to create/change/delete something, this is either
    >>> directly
    >>> commited to the DB (context.commitChanges()) or rolled back in
    >>> case of
    >>> an error (context.rollbackChanges()). As the datacontext is kept per
    >>> thread its objectstore will run full of data which will probably be
    >>> never used again. Is there a way to clear the objectstore (expect
    >>> calling unregisterNode() for each created object by hand)? Should I
    >>> create a new datacontext for a thread after a while?
    >>>
    >>> Any ideas? Thanks in advance.
    >>> Krzysztof
    >>>
    >>
    >>
    >>
    >
    >



    This archive was generated by hypermail 2.0.0 : Wed Aug 27 2008 - 08:52:52 EDT