>> Also im curious as to what kinda clustering issues are there when you distribute it out on your farm. does your controller create a bottleneck issue?
I'll let you know when I do. Single sign-on/fail-over/network transparency have all been deemed crucial to our business, so we are taking our time evaluating these techniques before deployment. Clarification: When I wrote "1000+ concurrent users" I am obviously talking about open connections and not business transactions. Even on high volume sites, simultaneous transactions are lower in number than concurrent user sessions. I am not sure how many simultaneous transactions occur given 1000+ concurrent users. I'm not saying that it doesn't happen, I just want to clarify that concurrent users does not usually equate to simultaneous database operations. On 11/21/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > If you're not talking about a large number of users, and you don't > need to cross JVM boundries, why use a DB at all? Why not just use a > static > concurrentHashMap and push the data back and forth that way? You'll have > less overhead and one less configuration item to worry about. > > --- Pat > > > -----Original Message----- > > From: djtrypt [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 21, 2005 11:33 AM > > To: [email protected] > > Subject: RE: Sharing an HTTPSession Between Apps > > > > well we looked into some In-memory DBs to store this and our current one > > we are thinking of implementing is HSQLDB (hypersonic SQL DB) which is > > 100% java based. > > > > Our app is still in beta phase so we wont have alot of concurrent users > > for a few months till we release v1.0, so i think an in-memory would be > > the easiest for our crew to set up, as we dont have a dedicated DBA at > the > > moment. SO if you know any let me know =P. > > > > Honestly after crunchin some number i dont either method we have talked > > about would be a speed issue, as since the data is so nominal it wont > get > > stuck in bottlenecks. > > > > I think HSQLDB would be a fine match for us atm, as its very small > (about > > 115K) and each row costs 100bytes of memory. and we have no more then > 12KB > > of data to pass, so with that said even at 1000 concurrent users, thats > > what 12 MB of RAM. I think we can afford that. =P > > > > however once we get an established Data Model going, ill prolly write a > C > > app to handle our Data Model more efficent then what will will start > with. > > > > thanx for your time the stats are useful > > > > evan m rawson > > > > > > -------------------- m2f -------------------- > > > > Sent from www.TapestryForums.com <http://www.TapestryForums.com> > > > > Read this topic online here: <<topic_link>> > > > > http://www.tapestryforums.com/viewtopic.php?p=10986#10986 > > > > -------------------- m2f -------------------- > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
