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 <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 - 01:08:48 EST