>> Using Database session seems like an oxy... I understand your concern. However, it doesn't need to be. At the time of this writing we have 44,641,040 rows in the table in question. We occasionally purge it. A single session check under load reports the following io figures:
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server parse and compile time: CPU time = 1 ms, elapsed time = 1 ms. SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. (1 row(s) affected) Table 'XXXXXXXX'. Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// I'm not entirely sure how many other users were accessing this table simultaneously when I ran this, but considering it's a Monday I'm sure it is well over a thousand. As you can clearly see, the impact on the db is negligible. With regards to network limitations, considering the small amount of information being passed over the network I wouldn't worry so much about it. If your site will truly be highly concurrent there are many other OLAP/OLTP queries that will be likely candidates for network congestion overhead. However, at this point the problem is dependent on your hardware. Having said all that, we are looking into clustering technologies for this and many other reasons. Still, clustering sessions across out entire farm will not be efficient either. This is not a trivial problem. On 11/21/05, Tapestry <[EMAIL PROTECTED]> wrote: > > thanx alot for the great information. Makes my brain churn up some > solutions. > > Infact after i wrote my last reply i kinda thought up a similiar solution > which answers my question of figuring out which session is which ^_^ > > There is very lil information we need t o pass between these apps, as 99% > of the data is queried outta our DB and is application specific. Meaning i > dont need to know the users registration information variables, for when > they go onto there account or checkout process. Our current design is to > have one nexus that selects where the user should be redirected to; our > pageSelector process. > > The only information we will need to store would be unique session Token > identifier, what application they are going to, what application they are > coming from, and user id. Splitting up our application into multiple apps is > merely a means to manage load balancing and devolpement easier, as our > projects contains appr. 1000 pages, span 12 site catagories. > > Using Database session seems like an oxy as at high volume you would have > a crap load of concurrent users connected to your DB, doesn't that > dramatically increase server load and slow net speed? However your points > about queries we have already taken into consideration. I foresaw that > blocking queries would be security flaw of this system. So we will design a > working catch system to prevent this. thanx for the heads up. > > Thanx alot you guys for your time. This has turned into an interesting > conversation. > > 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=10974#10974 > > -------------------- m2f -------------------- > > > >
