If any individual User only has a few attributes, then a oneToMany is fine. If a User had 5,000 attributes, it would not be fine.
200,000 instances is a lot, but "a lot" depends on your hardware, RAM, heap size, etc. With 200,000 simultaneous connections, I'm assuming this is a monster server. So it will probably be ok. Before you go too far I'd just run a load test and see how it works. On Fri, Mar 13, 2009 at 11:46 AM, John Whish <[email protected]>wrote: > Hi Brian, I might be going down completely the wrong path with this. > I'm expecting 200,000 users logged in at once. The idea is to "encapsulate > what changes" and stick all user attributes that aren't common to all users > into another class. Users will probably only have 3-4 specific attributes > (although as the system grows it will no doubt be added to). > As I understand it, 200,000 x 4 is a lot of objects to store in the > transfer cache so it will be constantly instantiating those objects. > Originally I was using the proxy before I decided to try storing a struct > directly in the User object. > > As I get the user object when they log in I don't see how I could use a > manyToOne > in this scenario. > > I got the idea from the heads up OOA&D guitar store example, if that helps. > > > > --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
