IMO Tapestry shouldn't try and guess how to synchronize access to visit object. The framework knows nothing about it after all...
Andrus
------------------------------ Andrei (aka Andrus) Adamchik Cayenne Object-Relational Framework http://objectstyle.org/cayenne/
On Apr 10, 2005, at 10:03 PM, T.Mikov wrote:
Benjamin Tomasini wrote:If you are concerned about this, here are some ideas:
- I doubt you would want to have the engine-class have synchronized
access to the visit object. The scope there is too big.
- Since the visit-object is just an arbitrary container of your session
state, you could very easily make its methods sychronized. Tapestry is
agnostic here.> > I don't know how useful this approach would really be.
That is what I am doing currently - my Visit classes are internally thread safe. It requires some care and can get complicated. The problem is that making the methods synchronized is not enough - typical code assumes exclusive access to the visit object inside a single request cycle. Imagine this scenario:
if (visit.isLoggedOn()) { .... doSomething( visit.getLoggedOnUser() ) }
The user could have logged out from another browser window between the the call to isLoggedOn() and getLoggedOnUser().
I am concerned that either my understanding is wrong, or most of the Tapestry examples out there (including the ones in the book) are potentially broken.
In the unlikely case that the latter is true, perhaps one possible fix is to synchronize the request cycle on the session (or may be that is already done inside Tapestry ?). Since most code I've seen already depends on the assumption that it has exclusive access to the visit object, that should take care of the problems. In the unlikely case of two browser windows accessing the same session, there will be minimal synchronization delay, but correctness will be preserved.
regards, Tzvetan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
