db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3849) Session data
Date Wed, 19 Nov 2008 01:49:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648875#action_12648875

Kristian Waagan commented on DERBY-3849:

I'm wondering if setClientInfo and getClientInfo in Connection can be used for this?
See specifically the JavaDoc for Connection.setClientInfo(String,String).

Although this hasn't been properly implemented for Derby yet, it shouldn't be too hard to
add. The question is where we want to store the information, and how it can be retrieved.

In triggers, maybe we can just use Connection.getClientInfo on the default connection? This
requires that the default connection inherit the information from the parent/main connection.
The connection can be obtained with DriverManager.getConnection("jdbc:default:connection").

Is there a need to obtain this information through SQL as well?
If so, is there a standard way of doing it?

As a first step, would accepting the three mentioned properties from the JavaDoc, simply storing
them in the Connection object itself, be sufficient?

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

View raw message