[
https://issues.apache.org/jira/browse/DERBY-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650426#action_12650426
]
Dag H. Wanvik commented on DERBY-3849:
--------------------------------------
I didn't notice DatabaseMetaData.getClientInfoProperties. I agree it probably
means
we should limit the set of properties to a fixed one. Perhaps we could add a
4th called "ClientInfo" or some such?
Then the app could use that for whatever is wanted.
I agree with you on the persistency question too. Storing it in the connection
object seems right to me.
> Session data
> ------------
>
> Key: DERBY-3849
> URL: https://issues.apache.org/jira/browse/DERBY-3849
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Environment: N/A
> Reporter: Antonio Sánchez
> Priority: Minor
>
> Being able of storing session data the same way a Java application does with
> HttpSession.
> Some applications might require this feature or could take advantage of it
> in order to fulfill its requirement more easily.
> Next I will describe an example scenario but there might be many others that
> would benefit of this feature:
> "A client/server (java-swing/derby) application that requires connecting to
> derby always using the same database user; the application users are stored
> in a an application table, e.g., APPUSERS. The application also requires
> auditing the activity of the connection via 'triggers' but having the current
> application user the 'owner' or 'responsible' of the database connection.
> The problem is that there is no way of tracking the application user
> corresponding to a database connection. For instance: given this scenario, if
> we have application users 'foouser' and 'baruser' and the connecting database
> user 'derbyconnect' , CURRENT_USER will return always 'derbyconnect' for
> both 'foouser' and 'baruser' connections. Althouht it is true that we could
> create a table where application connections are managed, at the time of the
> audit triggers run there won't be a way of relating the running physical
> connection (derby connection user) with the logical one (application user).
> Having the chance of storing data for a physical connection (session) would
> make it work, just by storing the application user in the session and
> retrieving it when needed in the triggers. Otherwise the application would be
> forced to perform an extra request in order to carry out the audit operation
> passing the application user as an argument, which would make worse both
> performance and application design."
> I am not an expert neither on derby nor in databases and maybe derby already
> provides the way of fulfilling this without the need of developing a new
> feature; if that it is the case I would appreciate if someone could let me
> know. But it there is no way, then I think this one would be a great feature
> for application developers using derby in scenarios like the one described
> above.
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
