cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <>
Subject Re: setToOneTarget not works for two transient objects (3.1B1)
Date Wed, 07 Nov 2012 12:30:42 GMT
On 7/11/12 9:42pm, Garth Keesler wrote:
> Interesting. So your ROP App is shared read, per user write. Right? In that case, can
multiple users be changing the same object from the read-only context or do you move the object
to the dedicated writable context?

In this case, we take a copy of the object (or just fetch a fresh copy from the database)
into a new context.

>This would seem to place the work of concurrency back on the database, correct? Is this
a requirement with Cayenne, much as it was with Ibatis (now Mybatis)? I guess my REAL question
is this: Is Cayenne designed to be an Object Manager or an Object Relational Mapper, particularly
in the ROP environment where multiple users interact with the same server app simultaneously?

I don't really understand the question, but in any complex system you need to think about
data caching and staleness of data plus concurrency issues. Will you optimistically lock your
objects or add a pessimistic locking strategy?  The tools are all there to solve these issues,
but the solutions depend on your needs.


> I've done a lot of reading about Cayenne but this remains unclear to me.
> Thanx,
> Garth
> On 11/07/2012 04:22 AM, Aristedes Maniatis wrote:
>> It all depends. One usage pattern is to create a long lived "read-only" context which
handles the bulk of data in the application which is not editable by users. Then you'll use
localObject to copy objects into a new context as needed (perhaps a shopping basket in a web
>> In my thick client ROP application, we have one shared context used for all the list
views (not editable). But when a user double clicks on a row, we create a new editing context
into which they will save any changes. They might have 10 windows open at once, so we we have
10 contexts. When they save a window, we save the context and throw the whole thing away.
>> We also create child contexts for 'sheets'. (Think OSX style dialogs which are modal
within a window).
>> For web applications, having a single context which lasts as long as the session
is probably quite a common pattern.
>> Ari
>> On 7/11/12 8:31pm, Garth Keesler wrote:
>>> Is the general case that a context typically lasts as long as the transaction,
gets discarded, and a new one is created for the next transaction or is it dependent on usage
in the program? For example, a web app as discussed here discards contexts based on user interactions
while a thick client app would tend to reuse the same context.
>>> Just curious...
>>> Garth
>>> On 11/07/2012 12:51 AM, Aristedes Maniatis wrote:
>>>> On 7/11/12 4:57pm, Alexey Katorgin wrote:
>>>>>> You should always create a context and then create objects within
that context
>>>>> using the methods Cayenne
>>>>>> gives you. This is different to the undecorated POJO that Hibernate
allows you
>>>>> to create.
>>>>>> Ari
>>>>> I develop a web-app and if I will create entities bounded to a dataContext,
>>>>> after user has leaved the page (by browser navigation buttons, closing
the tab,
>>>>> etc.) such entities will stay uncommitted and may be in inconsistency
>>>>> (user has not filled all required fields). And on the next commit this
>>>>> will be committed and raise validation exception.
>>>>> It is the reason why I want to use unbounded dataObjects.
>>>>> So I've decide to use transient objects not bounded to any dataContext.
In this
>>>>> case such object just be removed by garbage collector after user leaved
>>>>> unexpectedly. And where user will click OK, such objects will be manually
>>>>> attached to a dataContext and committed.
>>>>> It makes my code less clearly if can't set relationships between transient
>>>>> objects. Because I need to create additional temporary lists to store
>>>>> transient entities and iterate its to register to a dataContext before
>>>>> committing.
>>>>> What is the best practice for this use case?
>>>> Typically you bind a context to the user session so that the user can continue
to navigate through the site and not lose the work they have done but not yet saved. For example,
they may assemble a shopping basket, contact details and payment information. Then you commit
the whole thing atomically at the end.
>>>> Don't think of a data context as something you create when you are ready
to save. Think of it as a big bucket into which you put all the objects you are working with.
At the end, throw it away and make a new one, or commit it to the database. For more complex
arrangements read up on how to create parent/child contexts, but you don't need to do that
here. Start simple.
>>>> Make as many contexts as you need to have buckets of different information.
>>>> Ari

Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message