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 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.
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 state
(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
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
