You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2013/04/27 02:02:05 UTC
HA DataSource
Noticed the work going on with TOMEE-912 and wanted to make sure it hit the dev list.
Anish, if you have any insight on this feature request that'd be wonderful. Some questions:
- Is this feature intended for use involving database writes and transactions?
- Is this really load balancing rather than failure recovery? I.e. when should the functionality kick in, a or b or both?
a) Load-balancing scenario: before starting a transaction, pick a datbase using some selection strategy (round-robin, random, sticky, etc.)
b) Failure scenario: while in a transaction communicating with a databse, if it fails to respond then failover to another database using some selection strategy (round-robin, random, sticky, etc.)
I can see A being very doable. Doing B could also possibly be doable as long as no writes were involved.
If you have any information you can share about your setup that'd be wonderful.
-David
Re: HA DataSource
Posted by dsh <da...@gmail.com>.
I suspect no. If using HADR, DB high availability wouldn't be exposed up to
the application server and thus you could implement HA for both the DBMS
and the app server independently. If I get it right you could as well use
InfoSphere Change Data Capture to do the mere replication part.
Cheers
Daniel
On Sat, Apr 27, 2013 at 4:14 PM, dsh <da...@gmail.com> wrote:
> Are we talking about a DB2 HADR setup here?
>
> Cheers
> Daniel
>
>
> On Sat, Apr 27, 2013 at 3:15 PM, Anish Khanzode <ak...@gmail.com>wrote:
>
>> Hi David,
>>
>>
>> This is not really load balancing but mainly for failover with stickyness.
>> The feature we use this for is 2 DB2 Databases with Q-replication .
>>
>> Here is a presentation our DBAs gave on how we use Q-Replication.
>>
>>
>> https://www-950.ibm.com/events/wwe/iod/iod10cms.nsf/download/ke17c18673b943b9412badbbabb6/$FILE/IOD2010_TLU-2027.pdf
>>
>> I believe DB2 driver knows how to failover once it knows server list....I
>> will confirm that on Monday.
>>
>> Thanks
>> Anish
>>
>>
>> On Fri, Apr 26, 2013 at 8:02 PM, David Blevins <david.blevins@gmail.com
>> >wrote:
>>
>> > Noticed the work going on with TOMEE-912 and wanted to make sure it hit
>> > the dev list.
>> >
>> > Anish, if you have any insight on this feature request that'd be
>> > wonderful. Some questions:
>> >
>> > - Is this feature intended for use involving database writes and
>> > transactions?
>> > - Is this really load balancing rather than failure recovery? I.e.
>> when
>> > should the functionality kick in, a or b or both?
>> > a) Load-balancing scenario: before starting a transaction, pick a
>> > datbase using some selection strategy (round-robin, random, sticky,
>> etc.)
>> > b) Failure scenario: while in a transaction communicating with a
>> > databse, if it fails to respond then failover to another database using
>> > some selection strategy (round-robin, random, sticky, etc.)
>> >
>> >
>> > I can see A being very doable. Doing B could also possibly be doable as
>> > long as no writes were involved.
>> >
>> > If you have any information you can share about your setup that'd be
>> > wonderful.
>> >
>> >
>> > -David
>> >
>> >
>> >
>> >
>>
>
>
Re: HA DataSource
Posted by dsh <da...@gmail.com>.
Are we talking about a DB2 HADR setup here?
Cheers
Daniel
On Sat, Apr 27, 2013 at 3:15 PM, Anish Khanzode <ak...@gmail.com> wrote:
> Hi David,
>
>
> This is not really load balancing but mainly for failover with stickyness.
> The feature we use this for is 2 DB2 Databases with Q-replication .
>
> Here is a presentation our DBAs gave on how we use Q-Replication.
>
>
> https://www-950.ibm.com/events/wwe/iod/iod10cms.nsf/download/ke17c18673b943b9412badbbabb6/$FILE/IOD2010_TLU-2027.pdf
>
> I believe DB2 driver knows how to failover once it knows server list....I
> will confirm that on Monday.
>
> Thanks
> Anish
>
>
> On Fri, Apr 26, 2013 at 8:02 PM, David Blevins <david.blevins@gmail.com
> >wrote:
>
> > Noticed the work going on with TOMEE-912 and wanted to make sure it hit
> > the dev list.
> >
> > Anish, if you have any insight on this feature request that'd be
> > wonderful. Some questions:
> >
> > - Is this feature intended for use involving database writes and
> > transactions?
> > - Is this really load balancing rather than failure recovery? I.e. when
> > should the functionality kick in, a or b or both?
> > a) Load-balancing scenario: before starting a transaction, pick a
> > datbase using some selection strategy (round-robin, random, sticky, etc.)
> > b) Failure scenario: while in a transaction communicating with a
> > databse, if it fails to respond then failover to another database using
> > some selection strategy (round-robin, random, sticky, etc.)
> >
> >
> > I can see A being very doable. Doing B could also possibly be doable as
> > long as no writes were involved.
> >
> > If you have any information you can share about your setup that'd be
> > wonderful.
> >
> >
> > -David
> >
> >
> >
> >
>
Re: HA DataSource
Posted by Anish Khanzode <ak...@gmail.com>.
Hi David,
This is not really load balancing but mainly for failover with stickyness.
The feature we use this for is 2 DB2 Databases with Q-replication .
Here is a presentation our DBAs gave on how we use Q-Replication.
https://www-950.ibm.com/events/wwe/iod/iod10cms.nsf/download/ke17c18673b943b9412badbbabb6/$FILE/IOD2010_TLU-2027.pdf
I believe DB2 driver knows how to failover once it knows server list....I
will confirm that on Monday.
Thanks
Anish
On Fri, Apr 26, 2013 at 8:02 PM, David Blevins <da...@gmail.com>wrote:
> Noticed the work going on with TOMEE-912 and wanted to make sure it hit
> the dev list.
>
> Anish, if you have any insight on this feature request that'd be
> wonderful. Some questions:
>
> - Is this feature intended for use involving database writes and
> transactions?
> - Is this really load balancing rather than failure recovery? I.e. when
> should the functionality kick in, a or b or both?
> a) Load-balancing scenario: before starting a transaction, pick a
> datbase using some selection strategy (round-robin, random, sticky, etc.)
> b) Failure scenario: while in a transaction communicating with a
> databse, if it fails to respond then failover to another database using
> some selection strategy (round-robin, random, sticky, etc.)
>
>
> I can see A being very doable. Doing B could also possibly be doable as
> long as no writes were involved.
>
> If you have any information you can share about your setup that'd be
> wonderful.
>
>
> -David
>
>
>
>
Re: HA DataSource
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
thanks for pointing this out, completely forgot this registry!!! Thanks
David.
About git: we should more largely discuss our "infra" choices IMO
(typically maven compiler plugin has big issues ATM with version we use so
we have to address it or decide to go ahead using gradle which can ease our
tomee modules which are not really "under convention"), i'm rather for git
today since that's the 4th time i need it and feel a bit naked with svn.
IMO it will be worse when we'll fork to work on JavaEE 7 so maybe the moment
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/4/29 David Blevins <da...@gmail.com>
> You're getting closer with the last two commits. You'll want to remove
> that map that uses the Transaction object as a key. There's an object
> provided by the TransactionManager for doing this kind of registering and
> does all required cleanup as well, so there can be no leaks.
>
> See the code just after the slide titled "The DataSource You Get". The
> object you want is the TransactionSynchronizationRegistry
>
>
> http://tomee.apache.org/presentations/2012_JAXConf_Tomcat_to_JavaEE_with_TomEE.pdf
>
> I suspect you're still hacking, but ReverseFailOverRouterTest and
> FailOverRouterTest now fail. Sometimes I wonder if we wouldn't be better
> off with git. Only so many people can experiment on trunk like this --
> basically one. Not really a pressing issue now, but something to think
> about when we get more active people.
>
>
> -David
>
>
> On Apr 28, 2013, at 12:22 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Do you have a test showing it is not the case?
> > Le 28 avr. 2013 01:22, "David Blevins" <da...@gmail.com> a
> écrit :
> >
> >> In the JTA case, the getConnection method must return the same
> connection
> >> associated with the transaction. No failing over.
> >>
> >> -David
> >>
> >> On Apr 27, 2013, at 1:20 PM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >>> @David: works with jta case since connection is kind of singleton for
> >> this
> >>> case
> >>>
> >>> but clearly designed for read case
> >>>
> >>> that said a lot of db support better solution and service ip is easier
> to
> >>> handle if you have an admin team
> >>>
> >>> *Romain Manni-Bucau*
> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >> http://rmannibucau.wordpress.com/>
> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>> *Github: https://github.com/rmannibucau*
> >>>
> >>>
> >>>
> >>> 2013/4/27 David Blevins <da...@gmail.com>
> >>>
> >>>> Had a quick look through the code and, definitely, it could only be
> used
> >>>> for read-only cases where no JTA transaction or transaction of any
> kind
> >> was
> >>>> needed.
> >>>>
> >>>> Anish, this doesn't sound at all like what you are after. You seem to
> >> be
> >>>> after a way to configure a feature on your DB2 driver itself. From
> just
> >>>> the description, it sounds like this driver will repeat the queries on
> >> all
> >>>> databases configured akin to a disk raid level 1 (mirroring).
> >>>>
> >>>> Can you verify with your DB administrators?
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>> On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> Reproduced jboss behavior by.default. concretely: if getconnection
> >> fails
> >>>>> then try next db.
> >>>>>
> >>>>> I added strategy for read only cases (rdbms have an issue with write
> >> case
> >>>>> by design)
> >>>>> Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a
> >>>> écrit :
> >>>>>
> >>>>>> Noticed the work going on with TOMEE-912 and wanted to make sure it
> >> hit
> >>>>>> the dev list.
> >>>>>>
> >>>>>> Anish, if you have any insight on this feature request that'd be
> >>>>>> wonderful. Some questions:
> >>>>>>
> >>>>>> - Is this feature intended for use involving database writes and
> >>>>>> transactions?
> >>>>>> - Is this really load balancing rather than failure recovery? I.e.
> >> when
> >>>>>> should the functionality kick in, a or b or both?
> >>>>>> a) Load-balancing scenario: before starting a transaction, pick a
> >>>>>> datbase using some selection strategy (round-robin, random, sticky,
> >>>> etc.)
> >>>>>> b) Failure scenario: while in a transaction communicating with a
> >>>>>> databse, if it fails to respond then failover to another database
> >> using
> >>>>>> some selection strategy (round-robin, random, sticky, etc.)
> >>>>>>
> >>>>>>
> >>>>>> I can see A being very doable. Doing B could also possibly be
> doable
> >> as
> >>>>>> long as no writes were involved.
> >>>>>>
> >>>>>> If you have any information you can share about your setup that'd be
> >>>>>> wonderful.
> >>>>>>
> >>>>>>
> >>>>>> -David
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: HA DataSource
Posted by David Blevins <da...@gmail.com>.
You're getting closer with the last two commits. You'll want to remove that map that uses the Transaction object as a key. There's an object provided by the TransactionManager for doing this kind of registering and does all required cleanup as well, so there can be no leaks.
See the code just after the slide titled "The DataSource You Get". The object you want is the TransactionSynchronizationRegistry
http://tomee.apache.org/presentations/2012_JAXConf_Tomcat_to_JavaEE_with_TomEE.pdf
I suspect you're still hacking, but ReverseFailOverRouterTest and FailOverRouterTest now fail. Sometimes I wonder if we wouldn't be better off with git. Only so many people can experiment on trunk like this -- basically one. Not really a pressing issue now, but something to think about when we get more active people.
-David
On Apr 28, 2013, at 12:22 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Do you have a test showing it is not the case?
> Le 28 avr. 2013 01:22, "David Blevins" <da...@gmail.com> a écrit :
>
>> In the JTA case, the getConnection method must return the same connection
>> associated with the transaction. No failing over.
>>
>> -David
>>
>> On Apr 27, 2013, at 1:20 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> @David: works with jta case since connection is kind of singleton for
>> this
>>> case
>>>
>>> but clearly designed for read case
>>>
>>> that said a lot of db support better solution and service ip is easier to
>>> handle if you have an admin team
>>>
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>> *Github: https://github.com/rmannibucau*
>>>
>>>
>>>
>>> 2013/4/27 David Blevins <da...@gmail.com>
>>>
>>>> Had a quick look through the code and, definitely, it could only be used
>>>> for read-only cases where no JTA transaction or transaction of any kind
>> was
>>>> needed.
>>>>
>>>> Anish, this doesn't sound at all like what you are after. You seem to
>> be
>>>> after a way to configure a feature on your DB2 driver itself. From just
>>>> the description, it sounds like this driver will repeat the queries on
>> all
>>>> databases configured akin to a disk raid level 1 (mirroring).
>>>>
>>>> Can you verify with your DB administrators?
>>>>
>>>>
>>>> -David
>>>>
>>>> On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <rm...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Reproduced jboss behavior by.default. concretely: if getconnection
>> fails
>>>>> then try next db.
>>>>>
>>>>> I added strategy for read only cases (rdbms have an issue with write
>> case
>>>>> by design)
>>>>> Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a
>>>> écrit :
>>>>>
>>>>>> Noticed the work going on with TOMEE-912 and wanted to make sure it
>> hit
>>>>>> the dev list.
>>>>>>
>>>>>> Anish, if you have any insight on this feature request that'd be
>>>>>> wonderful. Some questions:
>>>>>>
>>>>>> - Is this feature intended for use involving database writes and
>>>>>> transactions?
>>>>>> - Is this really load balancing rather than failure recovery? I.e.
>> when
>>>>>> should the functionality kick in, a or b or both?
>>>>>> a) Load-balancing scenario: before starting a transaction, pick a
>>>>>> datbase using some selection strategy (round-robin, random, sticky,
>>>> etc.)
>>>>>> b) Failure scenario: while in a transaction communicating with a
>>>>>> databse, if it fails to respond then failover to another database
>> using
>>>>>> some selection strategy (round-robin, random, sticky, etc.)
>>>>>>
>>>>>>
>>>>>> I can see A being very doable. Doing B could also possibly be doable
>> as
>>>>>> long as no writes were involved.
>>>>>>
>>>>>> If you have any information you can share about your setup that'd be
>>>>>> wonderful.
>>>>>>
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: HA DataSource
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do you have a test showing it is not the case?
Le 28 avr. 2013 01:22, "David Blevins" <da...@gmail.com> a écrit :
> In the JTA case, the getConnection method must return the same connection
> associated with the transaction. No failing over.
>
> -David
>
> On Apr 27, 2013, at 1:20 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > @David: works with jta case since connection is kind of singleton for
> this
> > case
> >
> > but clearly designed for read case
> >
> > that said a lot of db support better solution and service ip is easier to
> > handle if you have an admin team
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/4/27 David Blevins <da...@gmail.com>
> >
> >> Had a quick look through the code and, definitely, it could only be used
> >> for read-only cases where no JTA transaction or transaction of any kind
> was
> >> needed.
> >>
> >> Anish, this doesn't sound at all like what you are after. You seem to
> be
> >> after a way to configure a feature on your DB2 driver itself. From just
> >> the description, it sounds like this driver will repeat the queries on
> all
> >> databases configured akin to a disk raid level 1 (mirroring).
> >>
> >> Can you verify with your DB administrators?
> >>
> >>
> >> -David
> >>
> >> On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >>> Hi
> >>>
> >>> Reproduced jboss behavior by.default. concretely: if getconnection
> fails
> >>> then try next db.
> >>>
> >>> I added strategy for read only cases (rdbms have an issue with write
> case
> >>> by design)
> >>> Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a
> >> écrit :
> >>>
> >>>> Noticed the work going on with TOMEE-912 and wanted to make sure it
> hit
> >>>> the dev list.
> >>>>
> >>>> Anish, if you have any insight on this feature request that'd be
> >>>> wonderful. Some questions:
> >>>>
> >>>> - Is this feature intended for use involving database writes and
> >>>> transactions?
> >>>> - Is this really load balancing rather than failure recovery? I.e.
> when
> >>>> should the functionality kick in, a or b or both?
> >>>> a) Load-balancing scenario: before starting a transaction, pick a
> >>>> datbase using some selection strategy (round-robin, random, sticky,
> >> etc.)
> >>>> b) Failure scenario: while in a transaction communicating with a
> >>>> databse, if it fails to respond then failover to another database
> using
> >>>> some selection strategy (round-robin, random, sticky, etc.)
> >>>>
> >>>>
> >>>> I can see A being very doable. Doing B could also possibly be doable
> as
> >>>> long as no writes were involved.
> >>>>
> >>>> If you have any information you can share about your setup that'd be
> >>>> wonderful.
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: HA DataSource
Posted by David Blevins <da...@gmail.com>.
In the JTA case, the getConnection method must return the same connection associated with the transaction. No failing over.
-David
On Apr 27, 2013, at 1:20 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> @David: works with jta case since connection is kind of singleton for this
> case
>
> but clearly designed for read case
>
> that said a lot of db support better solution and service ip is easier to
> handle if you have an admin team
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/4/27 David Blevins <da...@gmail.com>
>
>> Had a quick look through the code and, definitely, it could only be used
>> for read-only cases where no JTA transaction or transaction of any kind was
>> needed.
>>
>> Anish, this doesn't sound at all like what you are after. You seem to be
>> after a way to configure a feature on your DB2 driver itself. From just
>> the description, it sounds like this driver will repeat the queries on all
>> databases configured akin to a disk raid level 1 (mirroring).
>>
>> Can you verify with your DB administrators?
>>
>>
>> -David
>>
>> On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> Reproduced jboss behavior by.default. concretely: if getconnection fails
>>> then try next db.
>>>
>>> I added strategy for read only cases (rdbms have an issue with write case
>>> by design)
>>> Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a
>> écrit :
>>>
>>>> Noticed the work going on with TOMEE-912 and wanted to make sure it hit
>>>> the dev list.
>>>>
>>>> Anish, if you have any insight on this feature request that'd be
>>>> wonderful. Some questions:
>>>>
>>>> - Is this feature intended for use involving database writes and
>>>> transactions?
>>>> - Is this really load balancing rather than failure recovery? I.e. when
>>>> should the functionality kick in, a or b or both?
>>>> a) Load-balancing scenario: before starting a transaction, pick a
>>>> datbase using some selection strategy (round-robin, random, sticky,
>> etc.)
>>>> b) Failure scenario: while in a transaction communicating with a
>>>> databse, if it fails to respond then failover to another database using
>>>> some selection strategy (round-robin, random, sticky, etc.)
>>>>
>>>>
>>>> I can see A being very doable. Doing B could also possibly be doable as
>>>> long as no writes were involved.
>>>>
>>>> If you have any information you can share about your setup that'd be
>>>> wonderful.
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>
>>
Re: HA DataSource
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@David: works with jta case since connection is kind of singleton for this
case
but clearly designed for read case
that said a lot of db support better solution and service ip is easier to
handle if you have an admin team
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/4/27 David Blevins <da...@gmail.com>
> Had a quick look through the code and, definitely, it could only be used
> for read-only cases where no JTA transaction or transaction of any kind was
> needed.
>
> Anish, this doesn't sound at all like what you are after. You seem to be
> after a way to configure a feature on your DB2 driver itself. From just
> the description, it sounds like this driver will repeat the queries on all
> databases configured akin to a disk raid level 1 (mirroring).
>
> Can you verify with your DB administrators?
>
>
> -David
>
> On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi
> >
> > Reproduced jboss behavior by.default. concretely: if getconnection fails
> > then try next db.
> >
> > I added strategy for read only cases (rdbms have an issue with write case
> > by design)
> > Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a
> écrit :
> >
> >> Noticed the work going on with TOMEE-912 and wanted to make sure it hit
> >> the dev list.
> >>
> >> Anish, if you have any insight on this feature request that'd be
> >> wonderful. Some questions:
> >>
> >> - Is this feature intended for use involving database writes and
> >> transactions?
> >> - Is this really load balancing rather than failure recovery? I.e. when
> >> should the functionality kick in, a or b or both?
> >> a) Load-balancing scenario: before starting a transaction, pick a
> >> datbase using some selection strategy (round-robin, random, sticky,
> etc.)
> >> b) Failure scenario: while in a transaction communicating with a
> >> databse, if it fails to respond then failover to another database using
> >> some selection strategy (round-robin, random, sticky, etc.)
> >>
> >>
> >> I can see A being very doable. Doing B could also possibly be doable as
> >> long as no writes were involved.
> >>
> >> If you have any information you can share about your setup that'd be
> >> wonderful.
> >>
> >>
> >> -David
> >>
> >>
> >>
> >>
>
>
Re: HA DataSource
Posted by David Blevins <da...@gmail.com>.
Had a quick look through the code and, definitely, it could only be used for read-only cases where no JTA transaction or transaction of any kind was needed.
Anish, this doesn't sound at all like what you are after. You seem to be after a way to configure a feature on your DB2 driver itself. From just the description, it sounds like this driver will repeat the queries on all databases configured akin to a disk raid level 1 (mirroring).
Can you verify with your DB administrators?
-David
On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hi
>
> Reproduced jboss behavior by.default. concretely: if getconnection fails
> then try next db.
>
> I added strategy for read only cases (rdbms have an issue with write case
> by design)
> Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a écrit :
>
>> Noticed the work going on with TOMEE-912 and wanted to make sure it hit
>> the dev list.
>>
>> Anish, if you have any insight on this feature request that'd be
>> wonderful. Some questions:
>>
>> - Is this feature intended for use involving database writes and
>> transactions?
>> - Is this really load balancing rather than failure recovery? I.e. when
>> should the functionality kick in, a or b or both?
>> a) Load-balancing scenario: before starting a transaction, pick a
>> datbase using some selection strategy (round-robin, random, sticky, etc.)
>> b) Failure scenario: while in a transaction communicating with a
>> databse, if it fails to respond then failover to another database using
>> some selection strategy (round-robin, random, sticky, etc.)
>>
>>
>> I can see A being very doable. Doing B could also possibly be doable as
>> long as no writes were involved.
>>
>> If you have any information you can share about your setup that'd be
>> wonderful.
>>
>>
>> -David
>>
>>
>>
>>
Re: HA DataSource
Posted by Romain Manni-Bucau <rm...@gmail.com>.
And some uses service ip but for others that's needed
Le 27 avr. 2013 10:21, "dsh" <da...@gmail.com> a écrit :
> Some JDBC drivers already have that behaviour built-in and thus it becomes
> transparent to the client.
>
> Cheers
> Daniel
>
>
> On Sat, Apr 27, 2013 at 10:07 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > Hi
> >
> > Reproduced jboss behavior by.default. concretely: if getconnection fails
> > then try next db.
> >
> > I added strategy for read only cases (rdbms have an issue with write case
> > by design)
> > Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a
> écrit :
> >
> > > Noticed the work going on with TOMEE-912 and wanted to make sure it hit
> > > the dev list.
> > >
> > > Anish, if you have any insight on this feature request that'd be
> > > wonderful. Some questions:
> > >
> > > - Is this feature intended for use involving database writes and
> > > transactions?
> > > - Is this really load balancing rather than failure recovery? I.e.
> when
> > > should the functionality kick in, a or b or both?
> > > a) Load-balancing scenario: before starting a transaction, pick a
> > > datbase using some selection strategy (round-robin, random, sticky,
> etc.)
> > > b) Failure scenario: while in a transaction communicating with a
> > > databse, if it fails to respond then failover to another database using
> > > some selection strategy (round-robin, random, sticky, etc.)
> > >
> > >
> > > I can see A being very doable. Doing B could also possibly be doable
> as
> > > long as no writes were involved.
> > >
> > > If you have any information you can share about your setup that'd be
> > > wonderful.
> > >
> > >
> > > -David
> > >
> > >
> > >
> > >
> >
>
Re: HA DataSource
Posted by dsh <da...@gmail.com>.
Some JDBC drivers already have that behaviour built-in and thus it becomes
transparent to the client.
Cheers
Daniel
On Sat, Apr 27, 2013 at 10:07 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hi
>
> Reproduced jboss behavior by.default. concretely: if getconnection fails
> then try next db.
>
> I added strategy for read only cases (rdbms have an issue with write case
> by design)
> Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a écrit :
>
> > Noticed the work going on with TOMEE-912 and wanted to make sure it hit
> > the dev list.
> >
> > Anish, if you have any insight on this feature request that'd be
> > wonderful. Some questions:
> >
> > - Is this feature intended for use involving database writes and
> > transactions?
> > - Is this really load balancing rather than failure recovery? I.e. when
> > should the functionality kick in, a or b or both?
> > a) Load-balancing scenario: before starting a transaction, pick a
> > datbase using some selection strategy (round-robin, random, sticky, etc.)
> > b) Failure scenario: while in a transaction communicating with a
> > databse, if it fails to respond then failover to another database using
> > some selection strategy (round-robin, random, sticky, etc.)
> >
> >
> > I can see A being very doable. Doing B could also possibly be doable as
> > long as no writes were involved.
> >
> > If you have any information you can share about your setup that'd be
> > wonderful.
> >
> >
> > -David
> >
> >
> >
> >
>
Re: HA DataSource
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Reproduced jboss behavior by.default. concretely: if getconnection fails
then try next db.
I added strategy for read only cases (rdbms have an issue with write case
by design)
Le 27 avr. 2013 02:02, "David Blevins" <da...@gmail.com> a écrit :
> Noticed the work going on with TOMEE-912 and wanted to make sure it hit
> the dev list.
>
> Anish, if you have any insight on this feature request that'd be
> wonderful. Some questions:
>
> - Is this feature intended for use involving database writes and
> transactions?
> - Is this really load balancing rather than failure recovery? I.e. when
> should the functionality kick in, a or b or both?
> a) Load-balancing scenario: before starting a transaction, pick a
> datbase using some selection strategy (round-robin, random, sticky, etc.)
> b) Failure scenario: while in a transaction communicating with a
> databse, if it fails to respond then failover to another database using
> some selection strategy (round-robin, random, sticky, etc.)
>
>
> I can see A being very doable. Doing B could also possibly be doable as
> long as no writes were involved.
>
> If you have any information you can share about your setup that'd be
> wonderful.
>
>
> -David
>
>
>
>