Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cayenne-user@incubator.apache.org
Message-ID: <451D57F9.2090301@puregumption.com>
Date: Fri, 29 Sep 2006 12:29:29 -0500
From: Robert Zeigler <robertz@puregumption.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060812)
MIME-Version: 1.0
To: cayenne-user@incubator.apache.org
Subject: Re: Thread safety and Cayenne ( & Tapestry)
References: <c09652430609290646j2a84697v1216d35667ffc9ce@mail.gmail.com>
In-Reply-To: <c09652430609290646j2a84697v1216d35667ffc9ce@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

The multi-threading going on in tapestry (at least for tap3) is nothing
more than the "normal" multi-threading in servlet programming: each
request is handled by a separate thread.  The only extra thread tapestry
(3; can't speak for 4) starts is the "janitor thread" which cleans up
the pool.

As Michael Gentry pointed out, this means that if you have a
DataContext/session, you're generally safe: the behavior by most users
on pages of most webapps isn't going to create any threading issues,
because most users send a request for a single page at one time.
However, thread safety is not guaranteed. Consider the following situations:

  1) Using firefox, a user of your webapp middle clicks on several links
       (depending on your preferences, middle clicking in firefox will
open the associated link in a new tab in the background)
  2) You use frames (or iframes)
  3) Your site uses ajax (eg; g-mail, where g-mail could be
simultaneously saving an in-progress e-mail draft while checking for new
messages)

Each of those situations may result in concurrent requests ( =>
concurrent threads) accessing the same session.
As Andrus said, you'll have to consider the problematic operations and
manually synchronize.

Robert


�yvind Harboe wrote:
> Where can I read more about Cayenne and behaviour of objects when
> accessed from multiple threads simultaneously?
>
>
> We've screwed up a bit(how much I need to find out :-) when using
> Tapestry + Cayenne, but things work surprisingly well even so. That
> things appear to work fine is perhaps the scariest thing. I'd rather
> they'd break immediately.
>
> Basically we have multiple threads accessing/modifying a list of
> CayenneDataObjects.
>
> The problems started in our Visit object implementation in Tapestry:
>
> class Visit
> {
>  public List getFoo()
>  {
>    if (list==null)
>    {
>      List l=someCayenneQuery();
> Thread.sleep(5000);  // (A)
>      list=l;
>    }
>    return list;
>  }
> }
>
>
> Several problems:
>
> - There is a race condition. Context switch at (A) and a subsequent
> getFoo() invocation will will cause any number of someCayenneQuery()
> method calls thus each thread may be operating on a different list of
> objects.
> - Items might be added/removed from multiple threads. A simple
> LinkedList() is not thread safe, what about something returned from a
> Cayenne query?
>
> - How will a CayenneDataObject respond to multiple threads modifying
> properties?
>
> - How will a CayenneDataObject respond to multiple threads reading
> properties?
>
>
> Possible solutions for us that I'm pondering:
>
> - Read up more on Cayenne to understand the threading model better.
> Multiple threads reading/writing the same CayenneDataObjects may be
> fine.
> - I could single thread all modifications of the session/visit state.
> - use serialization somehow to create and write back a copy of each
> object per HTTP request.
> - Does some framework which can be used with Cayenne & Tapestry exist
> that can help me address the issues?
> - Can I make my Tapestry application single threaded? (I believe the
> answer is Bad Idea :-)
>
>