Re: DataContextPool

From: Cris Daniluk (
Date: Tue May 03 2005 - 09:46:52 EDT

  • Next message: Gentry, Michael \(Contractor\): "RE: Tapestry integration options"

    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 :)


    On 5/2/05, sastan <> 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