Remember that every session has its own copy of Visit, so the only
problems you would have would be created by a _single user_ accessing
Visit from more than one thread. That could happen, but it would
involve either multiple pages being accessed concurrently or someone
being click-happy. Either way, they should maybe expect to get
nonsense.
Todd
On Apr 10, 2005, at 11:09 PM, T.Mikov wrote:
Andrus Adamchik wrote:
I don't think anything is broken. Most applications will survive
users who click too fast. For those that won't it is trivial to
synchronize on a session-scoped object outside of Tapestry using
vanilla Servlet API, e.g. via a ServletFilter.
Broken is perhaps too strong, however unless I am wrong, the potential
for a problem is there in existing examples.
Take the Hangman application from "Tapestry in Action".
In the Guess page it invokes Visit.makeGuess(), which invokes
Game.makeGuess(), which modifies the game data. None of this uses any
synchronization, so it is possible that two threads will be making
concurrent modifications to the same data.
In general this is a serious problem. It should never happen, except
under very carefully controlled circumstances.
Of course in this simple case probably nothing really bad will happen
as a result.
I have seen this pattern in other examples, some perhaps with
potentially more serious problems. I haven't had time to analyze them.
I just want to make sure that this is an omission for the sake of
simplicity and there isn't some other mechanism taking care of
synchronization behind the covers.
regards,
Tzvetan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]