-----Original Message----- From: Research labs [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 5:17 PM To: Struts Users Mailing List Subject: Re: DaTASOURCE CREATION AT USER LOGIN TIME...Newbie
Craig, Thanks a lot. All points taken. In the light of what you and Jim have said, I will re examine my plan of action I found out about you in one of my books "Struts in Action" by Ted Husted et al. If I may, I would like to keep this first email from you as some sort of autograph. Ola. --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Mon, 2 Aug 2004 21:23:05 +0100 (BST), Research > labs > <[EMAIL PROTECTED]> wrote: > > Jim, > > > > Thanks for your response. > > I want each user to login to the database(MySQL), > via > > a JSP. Once logged in, I want them to use their > > database username (specified at log in time) for > > communicating with the database throught their > > session. To put it another way, if 4 users are > > currently logged in (via a JSP etc.), When I query > the > > data dictionary of the database, I want their > names to > > come up. At any point in time, I want to be able > to > > find out, who is logged in, this is why I do not > want > > everyone to log in with the same username and > password > > e.g. ola/ola-hardcoded in the Struts config's > > data-source. > > > > Do you care about finding out who is logged in to > your *application*, > or who is logged in to the *database*? Those can > easily be made > separate questions, and in most cases should be > separate. > > > I do not mind using any datasource so long as I > can > > achieve my objective. > > > > The <data-source> element in struts-config.xml, like > using most JNDI > provided data sources, will not address your need. > That is because > they create application wide pools for shared > connections. > > Doing what you want to do, however, will also be > giving up on the key > advantage of using a data source in the first place > -- sharing a small > number of database connections between multiple > users. By definition, > if you are using per-user logins to the database, > such connections > cannot be shared. That can be problematic for the > scalability of your > app, because it will require more database resources > to be allocated > than would otherwse be necessary. Plus, you'll > likely run into limits > on how many individual database connections can be > opened before you'd > ever run out of capacity in your web server to > support simultaneous > users. > > If all you care is logins to an application, here's > a couple of easy > ways to do that while still sharing database > connections: > > * At login time, write into some table someplace a > row for the logged in user, > and make sure you clean it up when they log out or > when the session > expires. To see who is logged in, run database > queries against > this table. > > * Store some in-memory data structure (perhaps as an > application scope > attribute), and have the login/logout logic add > and remove entries from > this data structure. To see who is logged in, set > up a Struts action or > something that will go through the data structure > and list all the logged > on users. > > If you still really want per-user database logins, > then give up on the > idea of using any sort of data source -- it won't > buy you anything. > Instead, create a standalone JDBC connection at > login time, and store > it in session scope somewhere. But I would suggest > you consider the > disadvantages of such an approach before using it. > > > Thanks. > > Ola. > > > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
