Ok, makes sense.
Adding an auto rollback option to the Cayenne web filter be a good, as
would a topic should in the Wiki doco.
Agreed. We may add this to the standard Cayenne filter, with the
rollback flag flipped on or off via the init-param in web.xml.
Andrus
On Mar 29, 2006, at 9:50 AM, Malcolm Edgar wrote:
Hi Andrus,
the use case is, I have a new User data object which has a Address
data
object property:
public Address extends CayenneDataObject {
..
}
public User extends CayenneDataObject {
public getAddress(); { .. }
public setAddress(Address address) { .. };
..
}
I am using a CayenneForm to create a new User and Address object in
one
post. To add the Address object to the User object, the User object
must
be registered with the DataContext for the relationship lookups.
With an invalid post all the submitted values must be validated before
creating a new User object, otherwise an invalid User object is
added to
the session DataContext.
I think the approach people advocate of always rolling back at the
end of
each request sounds like a good practice for most use cases. The
multi-page workflows could be handled by a separate DataContext
session.
Adding an auto rollback option to the Cayenne web filter be a good, as
would a topic should in the Wiki doco.
regards Malcolm Edgar
Andrus Adamchik <[EMAIL PROTECTED]>
27/03/2006 05:32 PM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: DataContext scope in web apps
Hi Malcolm,
I understand your question is also somewhat related to CAY-483 issue
that you opened recently.
I am finding that with the Cayenne web app design pattern where the
DataContext has session scope, it is easy to add objects to the
DataContext when building up an object graph for display.
Can you give an example. How can you add a new *persistent* object
that you don't want to commit? Is it only due to a programming error?
1. Using a request scope DataContext
With this I was thinking of a DataContext servlet filter which
creates a
new thread local DataContext for each request. If the user does not
explicitly commit changes in the data context, at the end of the
request
it will go out of scope and be garbage collected.
Issues with this appoarch could be performance cost of creating a
DataContext for each request (I dont know if this is an issue), and
the
loss of the session scope caching benefits the DataContext provides.
That's a possibility. There is very little overhead in new context
creation. There may (or may not) be a performance degradation due to
the loss of DataContext-level caching. This is application dependent.
Context cache saves you from doing extra DB trips for previously
resolved to-one and to-many relationships... also for the cached
queries if you use them.
2. Using nested DataContext with a request scope
The other idea is to create a nested DataContext from the parent
session
DataContext and bind this current thread. I imagine this would give
you
the benefits of session scope caching, but still enable you to
throw away
uncommitted data context objects at the end of the request. I
don't know
if it is any faster to create nested data contexts.
As you know nested DataContexts is a new feature, so we don't have
any empiric data on its performance (would love to get your
feedback). Performance overhead it adds is due to the fact that
select and commit operations have to travel through an extra
processing point in the stack. I would say it is appropriate for an
editor form that supposedly accesses/modifies no more than a few
[dozens] of objects; and not appropriate for a search page that may
access thousands of objects.
3. Another possibility - if you never ever carry uncommitted state
across requests, you can setup a filter that does
DataContext.rollbackChanges() at the end of the request. This is a
variation of the request-scope context, only preserving caching
benefits.
Andrus
----
This email is intended for the named recipient only. It may contain
information which is confidential, commercially sensitive, or
copyright. If you are not the intended recipient you must not
reproduce or distribute any part of the email, disclose its
contents, or take any action in reliance. If you have received this
email in error, please contact the sender and delete the message.
It is your responsibility to scan this email and any attachments
for viruses and other defects.
To the extent permitted by law, Zurich and its associates will not
be liable for any loss or damage arising in any way from this
communication including any file attachments. We may monitor email
you send to us, either as a reply to this email or any email you
send to us, to confirm our systems are protected and for compliance
with company policies. Although we take reasonable precautions to
protect the confidentiality of our email systems, we do not warrant
the confidentiality or security of email or attachments we receive.
