cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garth Keesler <>
Subject Re: setToOneTarget not works for two transient objects (3.1B1)
Date Mon, 12 Nov 2012 20:20:28 GMT
My fault. I kind of hijacked the thread. Very bad forum etiquette.


On 11/12/2012 07:13 AM, Andrus Adamchik wrote:
> I may have lost the thread of this discussion, so hopefully I am answering the right
question :)
> With nested contexts (and ROP as an extreme example of that), there are two basic commit
patterns - "ObjectContext.commitChanges()" and "ObjectContext.commitChangesToParent()".
> 'commitChanges', cascades commit all the way through to the database, adding uncommitted
changes of each context in the path of commit to the final DB transaction.
> 'commitChangesToParent' only commits to the immediate parent. So this can be used for
"lazy writes" if needed.
> It is up to the developer to create her own strategies based on these capabilities. E.g.
in Ari's case I would guess "commitChangesToParent" are used between multiple contexts of
the same parent user, but server-side contexts are dedicated to each user session and never
store uncommitted changes. This is the most common scenario AFAIK.
> But in some other app, you may have a shared server-side context to which multiple users
commit with 'commitChangesToParent', and then some even triggers a DB flush.
> Andrus
> On Nov 8, 2012, at 3:24 AM, Garth Keesler <> wrote:
>> My question really deals with whether or not Cayenne does lazy writes and I think
the answer is no. That avoids the need to coordinate committed-but-not-written objects across
different users within the same server executable. That seems to be the realm of Java EE and
not an ORM.
>> Let me know if I'm way off base here.
>> Thanx,
>> Garth
>> On 11/07/2012 06:30 AM, Aristedes Maniatis wrote:
>>> 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
>>> 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.
>>> Ari
>>>> 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 application).
>>>>> 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, and
>>>>>>>> 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 objects
>>>>>>>> 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 page
>>>>>>>> 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 all
>>>>>>>> transient entities and iterate its to register to a dataContext
>>>>>>>> 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
>>>>>>> Ari

View raw message