"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.
> 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.
> 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.
--
=====================================================================
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
