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.
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 type of functionality could be useful in other
circumstances as well. Perhaps Torque could be configured in the future
to implement data filtering based upon some arbitrary criteria.
Consider a simple human resources app where depending on the user
(manager, hr person, employee), the data returned from the database on
queries was automatically filtered by Torque.... This type of
functionality is often embedded into the application where it is often
duplicated in a few places. It is also very easy to forget to implement
the data filtering (depending, of course, on how you designed you
application). This type of approach could greatly simplify things.
The real drive behind why I am doing this is that I am trying to
use Oracle's Virtual Private Database technology. When each user logs
in, I will call a stored procedure passing in an identifier for the user
(user_id) and other data that will be used to restict data access. Each
time I obtain a pooled connection, I call another stored proc passing in
only the user_id. This gives Oracle enough information to dynamically
rewrite queries as they are executed adding more filters into the where
clause. This same idea is also supposed to apply to iserts, updates,
and deletes.
> -----Original Message-----
> From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 9:15 AM
> To: Turbine Users List
> Subject: Re: Passing TurbineUser info to the database
>
>
>
> I'll take a stab at this question...
>
> Each request could be on a different thread, therfore each
> request must set the user for the thread. The login action
> would only be called once at login, but the session validator
> is called on each request?
>
> "Eric Emminger <[EMAIL PROTECTED]> writes:
>
> > Quinton
> >
> > > I have need to pass the username of the person logged into my
> > > application to the database. The only way that I can see
> to really
> > > accomplish this is to call a stored procedure immediately after
> > > obtaining a pooled connection and calling it again when the
> > > connection is released to clear the name.
> >
> > This may be a naive response, but could you just do this in
> the Login
> > action?
> >
> > Eric
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
>
> --
> =====================================================================
> Jeffrey D. Brekke [EMAIL PROTECTED]
> Wisconsin, USA [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> 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]
