>> If you don't have the need or desire to have a unit of work span
>> requests, and none of the potential issues above apply, then I think
>> you are doing the right thing. I have used a similar technique in some
>> smaller webapps with no trouble...
>
> It sounds tenuous to span unit of work across requests since the
> committing request may never come. My application would be best
> served by ensuring things are written to the database as often as
> possible so that no one loses any work. In fact, I'll likely end up
> doing some AJAXy stuff that would save in the background even.
Sorry, too busy at the moment to comment on the bigger picture. A quick
note re: uncommitted state across requests.
While this may not be applicable to all applications, it is a useful and
commonly encountered case when you don't want to store incomplete data in
the database. It is not going to do you any good if a user commits step A
and then closes her browser and never commits step B of a multi-step data
entry process. But then again - it depends on the application..
Andrus
This archive was generated by hypermail 2.0.0 : Tue May 03 2005 - 08:53:19 EDT