A similar (or same) implementation that Assaf has mentioned below exists in
eWave Engine too.
http://www.ewavecommerce.com
-Bhaskar
>-----Original Message-----
>From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
>
>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".
>
===========================================================================
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".
