-
1. Re: High Availability JDBC
> Can anyone confirm whether or not JBoss Clustering
> has any support for HA JDBC connections/datasources?
>
>
> Weblogic provides database failover (rather than
> connection failover) via 'multipools'.
What's HA JDBC and multipooling?
#1 JDBC driver replicates each update against multiple DBs or
#2 database itself is replicated ?
Bela -
2. Re: High Availability JDBC
Hi bela,
In a High Availability deployment the database server is a single point of failure (SPOF).
What I am refering to is the ability to provide access to consistent data with a database failure. This implies that:
#1 The database is replicated/mirrored
#2 The application can be redirected to the replicated database
Ideally the solution to #2 means that the failover to the replica database is done behind the scenes and is transparent to the application.
Some JDBC drivers, like Oracle JDBC OCI, claim to be able to provide transparent failover of connections in a replicated environment.
Weblogic provides what it calls 'multipools', which enable you to setup a pool per database replica that share the same JNDI binding. Hence, when one replica fails applications are redirected to another 'multipool' (e.g. another replica) behind the scenes. But this only provides transparent db failure, so the application still has to cope with the connection failure.
So I was wondering how HA JBoss deployments mitigate the SPOF database issue.
Hope this helps, Owen -
3. Re: High Availability JDBC
Hi Owen,
> In a High Availability deployment the database
> server is a single point of failure (SPOF).
Yes. Currently JBoss HA only addresses shared DBs. Unshared (local DBS) is on the todo list.
> What I am refering to is the ability to provide
> access to consistent data with a database failure.
> This implies that:
>
> #1 The database is replicated/mirrored
Use DB replication tools a la Oracle Replication etc, or for prototyping hsqldb/r (async DB repl).
> #2 The application can be redirected to the
> replicated database
At the JDBC level ?
> Ideally the solution to #2 means that the failover to
> the replica database is done behind the scenes and
> is transparent to the application.
On the appserver level, JBoss HA allows fat (RMI) clients to failover to a different server when the primary access fails. However, this is somewhat orthogonal to failing over at the JDBC level.
I think for failing over at the JDBC level there are a number of products out there that do it.
> Some JDBC drivers, like Oracle JDBC OCI, claim to be
> able to provide transparent failover of connections
> in a replicated environment.
Got you. They probably work hand in hand with their Replication product.
> Weblogic provides what it calls 'multipools', which
> enable you to setup a pool per database replica that
> share the same JNDI binding. Hence, when one replica
> fails applications are redirected to another
> 'multipool' (e.g. another replica) behind the scenes.
> But this only provides transparent db failure, so the
> application still has to cope with the connection
> failure.
I see. So you have two levels of failover: client - appserver and appserver - DB. We currently only provide #1.
> So I was wondering how HA JBoss deployments
> mitigate the SPOF database issue.
No, not currently. But we're working on a replicated cache which would allow us to have each node (appserver instance) have a separate DB. All DB access goes through cache, cache replicates between nodes (and therefore DBs). At startup, new nodes acquire the DB state from existing ones, or from the DB directly if no existing nodes are running.
This won't be in JB4 DR0 though.
Bela -
4. Re: High Availability JDBC
I already thought about this jdbc thing a few times, it may be interesting to implement... (and not necessarly hard).
Anyone willing to start this development?
cheers,
sacha