> -----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]
