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]



Reply via email to