tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Fisher <>
Subject Re: Populating Oracle v$session.program from Tomcat Context.xml
Date Thu, 17 Mar 2011 01:33:02 GMT
> We'd like to be able to tell apart database sessions from the 15 or so
> tomcat applications we have running on our web-servers. Most of them
> use similar logins, so we can't query the username from gv$session. We
> were hoping to instead query to program field to tell them apart.
> We were able to make this functionality work with the thin client, but
> we'd rather use the OCI client because it allows our web-apps to
> reconnect to the database service after a loss of connectivity (say
> during a cluster node reboot).

I believe that it is possible to do "Fast Connection Failover" using the Thin driver. We were
on the verge of testing, but have been waiting months of some required Solaris patches to
be applied by our overworked Sysadmin. But it ought to be possible.

You have write your own ConnectionManager class. We plan to try these jars - ojdbc6.jar, ons.jar
and ucp.jar from Oracle.

Your connection string gets complex, but essentially ONS is contacted by the Oracle Grid Infrastructure
to reset connections.

Here is how we understand it for our aborted tests.

1) FCF helps do auto switch over in the java thin client
2) ONS passes to FCF the message sent to Data Guard from Oracle Restart during an auto switchover
or fail over. It also passes the message from Data Guard during a manual switchover.
3) Data Guard does the database switch over. 
4) Oracle Restart - monitors the data guard observer and triggers auto switch or fail over
via data guard. It also manages restarting other needed oracle applications in the right order.
Listener, dbconsole, agents, etc...

I'm interested if anyone has experience with it?


> So far though we've had no luck in getting it to work with OCI. Most
> of the suggestions and info out on the web imply that the best way to
> do it with OCI is programmatically from the java app. That's the
> dilemma. Do we have to take the time to change our apps to populate
> the program field, or can we do it from the context.xml file from our
> app?
> On Tue, Mar 15, 2011 at 8:23 PM, Jorge Medina
> <> wrote:
>> What is the problem that you are trying to solve?
>> On Mon, Mar 14, 2011 at 4:25 PM, Dan <> wrote:
>>> On Mon, Mar 14, 2011 at 11:25 AM, Dan <> wrote:
>>>> On Mon, Mar 14, 2011 at 10:57 AM, chris derham <>
>>>>>> We have some working tomcat 6 instances that we'd like to identify
>>>>> Can you use the combination of machine and schema name to identify the
>>>>> instance? You didn't detail your environment, but if you have a cluster,
>>>>> then the machine name would uniquely identify the instance. If you have
>>>>> multiple different instances on the same machine, then surely the schema
>>>>> name would allow you to identify which user it is? This covers all
>>>>> possibilities unless you have different apps on the same machine in
>>>>> different tomcat instances talking to the same schema.
>>>>> Chris
>>>> We are running all of our web-applications from two machines, and they
>>>> all use the same schema/username, so unfortunately I need the program,
>>>> client_info, module, etc field to identify them.
>>>> We are running a RAC, and I'm querying gv$session which should get me
>>>> all cluster member connections.
>>>> As David said, this does work with the thin driver, but I need the
>>>> service/load balancing functionality from OCI. Any more suggestions
>>>> are welcome!
>>> Does anyone else have any additional thoughts on this? I'd sure
>>> appreciate more input.
>>> TIA,
>>> Dan
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message