Since it seems like no one else has bit on this, I'll go ahead :)
This is probably a very bad idea. There are a few specific problems:
1. If you were to leave an object uncommitted and then finish the
request, the DataContext would be dirty for the next request, so you'd
have to auto-commit or rollback at hte end of the transaction.
2. The object graph is stored in the DataContext. The object graph
stored for user A is probably not as useful to user B, since it does
not reflect any of the data B has requested.
3. There are a lot of potential security problems in this arrangement.
The sky really is the limit on the fun someone could have.
The other thing I'd point out is that while I don't know tapestry well
enough to comment on its performance, I have a feeling that the total
cost of creating a visit is astronomically lower than even a single
JDBC operation. I really think optimization should be a response to
problems and not an anticipation of problems.
If you are truly worried, you could create a DataContext for each
request. That's going to be slow and ugly, but at least it will behave
consistently :)
Cris
On 5/2/05, sastan <sasta..-d-o-t.com> wrote:
> Hi,
>
> i develop a web app with tapestry. I saw some implementations where the
> datacontext is stored in the visit object. So for every user tapestry
> has to create a visit object which is expencive. Is it a better idea to
> create a DataContextPool from where a request can recieve a DataContext?
>
> sastan
>
>
This archive was generated by hypermail 2.0.0 : Tue May 03 2005 - 09:46:54 EDT