I don't agree with your implication that a user should only be reading from the
session, one example I am using is a wizard that uses an SSO over a few pages,
once all steps are completed only then is the data written to the database and
the SSO is discarded, using an SSO for this is natural choice imho, but even
that is beside the point Otto, as I have mentioned already I don't think its a
big deal since it is unlikely (although not impossible) that you will have
concurrency problems accessing the HttpSession, the original issue in question
is the multiple threads modifying persistent data, a 'get -> modify -> set'
pattern, which then has the potential to be wrong when re-reading the value.
Peter
----- Original Message -----
From: "Otho" <taa...@googlemail.com>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Wednesday, 15 July, 2009 11:43:23 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
2009/7/15 <p.stavrini...@albourne.com>
> Other than a flag that the framework will have to manage, I really don't
> see it being such a big deal... maybe I am naive and missing something, but
> do you think it is better for Tapestry users to manage this? having Atomic
> references and Synchronized blocks all over our code, it is easy to miss
> something when dealing with thread safety, and what of performance?
>
> Peter
>
For what would you need that (atomic refs and synchronized blocks)?
The above example is completely artificial. It doesn't make any sense (in a
webapp) to write data which you don't persist in some way.
When you start using the session with writable objects there is very
probably a flaw in your design.
Take a user object for example. Let's assume you have a manger user with
editing rights which shows some malicious behaviour. An admin jumps in and
disables the user in the database to prevent future damage while the manager
is logged in. Now this manager has his user object alongside with his access
rights in his own session "for convenient access" and your code relies on
that session... Until his session expires he can still do anything the admin
wanted to prevent.
To overcome this reliably there is no way around reading the user object
from the datastore on every request. This sounds worse than it is, since all
modern datastores have caches, and it is in any circumstance better than
throwing the user around in the session. @Persist("session") and
@SessionState really only make sense for read-only data or data which
doesn't need to be guarded against concurrent write-access like temporary
state.
For example two users works on an invoice in a billing system and alter
different data. When the first one submits it is committed to database. When
the second one commits the database throws an exception, when optimistic
locking is on. But it would be a good idea to have the second users
temporary data @Persist ed since now you can catch the exception and show
the differences between the committed version and his version for
information and let him think about and alter his input before he commits
his final version.
It's not only in MMOs where you should never ever trust the client (and thus
his session).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
