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 <andru..bjectstyle.org>
27/03/2006 05:32 PM
Please respond to
cayenne-use..ncubator.apache.org
To
cayenne-use..ncubator.apache.org
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.
This archive was generated by hypermail 2.0.0 : Wed Mar 29 2006 - 00:50:54 EST