Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <992CA196-9B57-4878-9C84-BCFC41B32E8D@objectstyle.org>
From: Andrus Adamchik <andrus@objectstyle.org>
To: user@cayenne.apache.org
In-Reply-To: <48B54BE0.5060105@janowicz.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Stateless server (GWT)
Date: Wed, 27 Aug 2008 15:52:14 +0300
References: <48B5394D.70507@janowicz.de>
 <9220A011-742C-4B0F-AC64-A19D7EF46F8E@objectstyle.org>
 <48B54BE0.5060105@janowicz.de>

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