Re: Users, sessions, data...
Well, my app is a game which you could call Excel, but in fantasy settings :) Modifying lots of tables and simple calculations, lots of them. Some people call that building, attacking, spellcasting... I have most of stuff atm in User entity, over 100 variables, some of them ArrayLists and HashMaps. Persistence with JDO and Guice to make things nicer. Right now I am putting whole User into session, then retrieving data from it. When user modified smth with a form, it would persist whole User to the db. Most of the time there is not much interaction - user walks around the app and looks at numbers, getting them every time from db and not from session seems ineffective. Of course consistency and workability are more important :) Smooth experience for users and no chance for bugs [ISE, blank pages, other user's data, out of order persists] is the most important thing here. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Users-sessions-data-tp3598626p3602085.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
Re: Users, sessions, data...
Hi Zeldor, Zeldor 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. In GAE/J your sessions are persisted to both the BigTable datastore (for guaranteed persistence) and the memcache (for speed of access). Retrieving data from the datastore is relatively fast (compared to writing to it) and from memcache even faster, so each of my session instances stores the user ID (only) of any logged-on user (or null if none). The session then retrieves any data from the datastore as needed (for example: user name, is-administrator-or-not). Be aware of the maximum session data size of 1MB for GAE/J (= maximum persistent entity data size). Don't fall into the trap I did by not using loadable detachable models for large amounts of data like photographs. Ian -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Users-sessions-data-tp3598626p3601823.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
Re: Users, sessions, data...
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 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 > >
Re: Users, sessions, data...
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
Re: Users, sessions, data...
> But what are benefits of small session really? With entire user in session I > can skip getting data from db and serve data faster... > wicket's (de-)serialization is not done in 0ms ;) but if that works for you then this strategy is great. and also if you have a lot of users or big user data (or both) then you'll quickly run out of memory for your app server another problem is that you'll have to make sure that the user is always redirected to the same server/node with the user its session data, which makes load balancing more complicated. -- http://jetwick.com open twitter search - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Users, sessions, data...
Zeldor wrote: > > But what are benefits of small session really? With entire user in session > I can skip getting data from db and serve data faster... > In clustered env small session get replicated much faster. I think that wicket's session shouldn't be used for storing any business data. Any data should be attached and loaded on per-component level, i.e. on demand (either from DB or external cache). - -- http://www.linkedin.com/in/amorozov -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Users-sessions-data-tp3598626p3599303.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
Re: Users, sessions, data...
But what are benefits of small session really? With entire user in session I can skip getting data from db and serve data faster... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Users-sessions-data-tp3598626p3598945.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
Re: Users, sessions, data...
Am 15.06.2011 08:36, schrieb Zeldor: > Hi, > > My last attempts to fix my session and advices here made me thinking if my > approach is good. So I'm curious - how do you handle users and their data? > In my case I have session, when user logs in entire entity gets loaded into > session. Later I get user data from that session and when he changes > anything it gets persisted to db. There is no direct interaction between > user and only that user can access his data. What is your approach? :) My approach is: load user data every time from DB. This way your session is always small or take a look to LoadableDetachableModel: https://cwiki.apache.org/WICKET/detachable-models.html Regards, Peter. -- http://jetwick.com open twitter search - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Users, sessions, data...
Hi, My last attempts to fix my session and advices here made me thinking if my approach is good. So I'm curious - how do you handle users and their data? In my case I have session, when user logs in entire entity gets loaded into session. Later I get user data from that session and when he changes anything it gets persisted to db. There is no direct interaction between user and only that user can access his data. What is your approach? :) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Users-sessions-data-tp3598626p3598626.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
