Hi All, thanks for the input - I really appreciate it.
I should have said that I'm looking at implementing this across 3 CF
enterprise servers and then having the load balancer point users to a
specific server and keep them on it (mind's gone blank but I think this is
called sticky session). So,
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
I had thought about doing a good ol' cfquery to pull out the values from the
db and just populate that way. Would certainly be quick.
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
I think it might even make more sense, because I'm not sure that you're
going to get any value from composition anyway. It doesn't sound like you
have a bunch of actual objects composed into your User object, but rather a
bunch of properties. So it might make more sense to treat them as
Hi Bob, yeah the objects are completely dumb so there is not value to
using composition. Using a query just seemed a bit hacky to me, having said
that if you think it's OK, then it's definitely good enough for me :)
Thanks for your thoughts.
--~--~-~--~~~---~--~~
Another solution I thought of was to just have all the getters and setters
for all the users properties which would be unused for most users. That
doesn't seem very clean to me either.
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
@Adam, that TIBO sounds interesting. Does it pick up the 'custom' behaviour
from the decorator or do you end up duplicating code?
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
Yes... basically it wraps the TransferDecorator using CF8's
onMissingMethod() functionality I would suggest that if you
haven't yet, go check out the work Peter Bell did with the coldfusion
IBO on riaforge.org.. The TIBO started as a slightly modified IBO, it
now has a fairly similar
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
I haven't done any load testing on ColdFusion or Transfer with
anywhere near that number of users, but as Brian said I'd do a really
quick spike and some load testing before you go too far with this.
Mark, shoot me down if I'm wrong, but I wouldn't call that number of
simultaneous users a
Thanks Brian.. your response is in line with my general understanding
of the o2m vs m2o relationships, and I was by no means blaming
Transfer for anything. I think I hijacked the thread and took it off
topic, but your post reminds me of a good blog I read and must have
forgotten about o2m vs
Yeah... I have to wonder at 200,000 simultaneous single users on a
single server, regardless of the application server, let alone the
framework. If you have that high a load, I'd be looking at a
clustered solution right off the bat.
Would anyone disagree with me?
Mark
On Sat, Mar 14, 2009 at
Either a cluster of separate servers or a monster system running numerous
instances.
On Fri, Mar 13, 2009 at 7:37 PM, Mark Mandel mark.man...@gmail.com wrote:
Yeah... I have to wonder at 200,000 simultaneous single users on a
single server, regardless of the application server, let alone the
13 matches
Mail list logo
