Update - This idea does work. In about a week or so, I should have a how to on how to do this.
> -----Original Message----- > From: Quinton McCombs > Sent: Friday, February 28, 2003 10:36 AM > To: Turbine Users List > Subject: RE: Passing TurbineUser info to the database > > > > -----Original Message----- > > From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 28, 2003 10:15 AM > > To: Turbine Users List > > Subject: Re: Passing TurbineUser info to the database > > > > > > "Quinton McCombs" <[EMAIL PROTECTED]> writes: > > > > > That is correct. > > > > > > It might be more clear to think about this from the torque > > end. When > > > Torque.getConnection() is called to get a database > > connection, I need > > > to know what the current user is. I have no reference to > > RunData, the > > > HttpRequest, or anything else that I could use to get back to the > > > user. My only real option here is to call a static method > that can > > > return the current user. > > > > > > The call to Torque.getConnection, the execution of the session > > > validation, and the execution of any action or screen class > > applicable > > > to producing the returned page will always execute in the > > same thread. > > > Using a static attribute that is an instance of ThreadLocal > > will allow > > > each thread to have its own copy of the data stored in the > > ThreadLocal > > > instance. This allows a call to a static method to get > the current > > > user to work. > > > > All those things happen on the same thread, but each request > > could be a different thread that the servlet container starts > > right? Point is, from Turbine, you'll need to set the user > > each time a request is processed by the servlet. > > Yes, each one could be on a different thread. Multiple > requests will be served concurrently with multiple thread (on > per request). That is why the user must be set again each > time.... The user information set in this manner has the > same lifetime (approx) as RunData. It is good for only one request. > > > > > > At least, I think this should work. I haven't tried it yet. > > > > > > More on the design - > > > > > > I am going to modify Torque so that you can register a > > listener class > > > of sorts. Basically, you will set a property in Torque.properties > > > with the class name of your listener class. If the listener is > > > configured, Torque will execute the appropriate method on > > the listener > > > class passing in the connection object. It will then return the > > > connection object. > > > > This really sounds more like the connection pooling should > > support this more than Torque. Maybe DBCP has this ability already. > > I looked there for the ability to configure some sort of pool > listener but I did not find anything. I may end up moving > this functionality into DBCP at some point because it does > seem to make more sense there. I am still trying to figure > out how I can execute code when the connection is returned > back to the pool. I don't think that I will be able to > implement that behavior unless I look at modifing DBCP > instead of Torque. > > For now, I am looking at putting the functionality into > Torque just to prove that everything will work as expected. > > > --------------------------------------------------------------------- > 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]
