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