One subtle gotcha to consider is that Wicket does not synchronize access to
your Session object when processing multiple requests by the same user.
Marking your Session's getters and setters as "synchronized" is sufficient
for simple data members, but typical use of entities cannot be considered
thread-safe. (With Hibernate this is clear because attached entities are
associated with a single Hibernate Session, which is definitely not
thread-safe. I'm not sure of the JPA equivalent terminology.)

For this reason, I maintain only the user ID in the Wicket Session, and
subclass WebRequestCycle to maintain request-scoped entities. (Your
WebRequestCycle is only used by the single thread servicing the request.)

Thanks to Igor and his Apache Wicket Cookbook for drawing my attention to
this issue. :)

Dan

On Wed, Jun 15, 2011 at 6:34 AM, Zeldor <pgronkiew...@gmail.com> wrote:

> Well, I'm hosting it on GAE and with new pricing model I have to worry
> about
> instances, not memcache or things like that. And I don't have to do load
> balancing. To be sure that data does not get lost between instances [which
> could happen probably with big traffic and longer inactivity from user] I
> can just have a check in getUser() method which could reload data from db
> if
> needed. I wonder if enabling multithreading could cause problems...
>
> Loading user every time from db would be probably too slow and could spin
> up
> too many instances due to that. Right now it looks like I can get data fast
> from session and do a persist in 15-30ms. Add time for all calculations of
> course. Numbers may be different with more users though.
>
> Anyway, I'm fairly new to programming and Wicket, so I don't know what's
> fast or reasonable. Just trying to figure if I'm going in good direction
> before it's too late to change it.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Users-sessions-data-tp3598626p3599401.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to