Somewhat alternative mechanism (sorry for the late reply), which we are
using.
The bean obtains a connection from the JNDI ENC (DataSource, not Driver)
which the container takes care of managing (pooling, enlistement, etc),
all in compliance with the J2EE specs (EJB + Servlets).
The transaction monitor is configured to bind a particular connection
pool to the given name. Although this is a TM API, you can go and switch
this binding while the server is up and running, and then switch it back
to the original binding.
Your beans are totally aware of the switch and keep on using
java:comp/env/jdbc/mydb (or any name that works for you), but get a
different connection from a different pool to a different server (could
be Oracle one day, Sybase the other, 200 connection limits in the
morning, 50 in the evening, etc).
arkin
Chris Raber wrote:
>
> Interesting dilema. I think the key is having a container that provides a
> level of redirection in its binding to Connections. We do this in GemStone/J
> under the hood. E.g., in order to integrate with GemStone/J's transaction
> manager, we create a JDBC driver wrapper, which delegates calls to the
> actual JDBC connection object. The wrapper is aware of the transaction
> environment, the underlying connections are not. The beans use the wrapped
> connection objects (un-beknownst to them), whose methods are delegated to
> the underlying Connection.
>
> Similarly, one could create a Connection wrapper that delegates calls to
> pooled connections based on which database is "current". A notification
> mechanism could hook in to automate the switch over.
>
> I am not saying we do this today, but it wouldn't be That hard. Steps to
> implement in GemStone/J:
>
> 1. Write an implementation of java.sql.Driver, that returns instances of
> Connection wrappers. Specify this driver class in the JDBC pool
> configuration.
>
> 2. Write an implementation of java.sql.Connection, that delegates call to
> the actual connection. These Connection objects would register themselves
> with a call back mechanism that provides for re-binding to a different JDBC
> URL under the hood. They would delegate all java.sql.Connection calls to
> their current underlying JDBC Connection.
>
> Some trickery would be required to handle the case where a Conneciton is in
> the middle of a transaction when the switchover callback is received. The
> switch-over call would have to block until the current transaction is
> complete. Presumably you would have some grace period in the switchover that
> allowed Connections to finish current work before change over.
>
> I have no idea whether this is doable in WL, but I suspect some other
> container/servers than GemStone/J may have similar architecture in this
> area, so it might be a solution you could apply.
>
> Regards,
>
> -Chris.
>
> > -----Original Message-----
> > From: Alain [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 01, 2000 1:31 PM
> > To: [EMAIL PROTECTED]
> > Subject: Database Switching
> >
> > Hello,
> >
> > here is quite a strange situation we have to deal with ...
> >
> > We have a series of Entity and Session Beans using a pool in order to
> > connect
> > to a database.
> > Nothing special exepect the fact that the database switches during the day
> > and
> > night for maintenance reasons. The weblogic server (4.5.1) can not be
> > shutdown
> > and the customer doesn't want to redeploy the beans at every switch. The
> > information on which
> > database is currently up is maintened in an administrative database that
> > is
> > stable and doesn't failover...
> >
> > So I was wondering what design pattern I could apply to cope with this
> > scenario ?
> >
> > 1) Is there a way to define a "virtual pool" that could bind me with the
> > currently active DB ?
> > 2) Should I proceed with a select to the admin datatabase every time, in
> > order to dynamicaly
> > determine which database (i.e pool) I should use ?
> > 3) Is there a way to update an env. property of the bean with the info in
> > the admin database ?
> >
> >
> >
> > Thanks in advance for all input.
> >
> > Alain
> >
> > ==========================================================================
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
