Vince,

Both the jdbcPersistenceAdapter and the leaseDatabaseLocker appear to
accept a dataSource parameter. I wasn't clear from your original question
whether you were using two different dataSource objects (each one pointing
to a different Oracle database). Your first sentence sounded like you were
doing that, but when you wrote "they share the connection pool and data
source" that sounds like maybe you're only using one dataSource. Can you
confirm that you're attempting this with two distinct dataSources and two
distinct connection pools? If that's not the configuration that's been
tried to date, please try it and see if that gets things working as
expected.

Tim

On Tue, Jul 13, 2021, 9:49 AM Tim Bain <tb...@alumni.duke.edu> wrote:

> Vince,
>
> Thanks for explaining the use case. I'm surprised to hear that moderate
> load is enough to make the lock table inaccessible, and it makes me
> question whether they have Oracle properly configured and on adequately
> sized hardware, but that's a separate question, for them to resolve if they
> choose.
>
> I'm not familiar enough with the configuration options for the database
> locker to know whether it's possible to support locking in a separate
> database, but I'll try to find time to look at it later this week or over
> the weekend. In the meantime, can you clarify whether your client is using
> the database locker or the lease database locker[1]? If they're using the
> former, it might be worth checking whether the latter eliminates the issues
> they're seeing, in cade the root cause relates to database connections
> being terminated (causing the brokers to initiate a failover).
>
> Tim
>
> 1. https://activemq.apache.org/pluggable-storage-lockers
>
> On Mon, Jul 12, 2021, 8:27 AM Vince Cox <v...@perforce.com> wrote:
>
>> Tim,
>>
>> I understand your point of view completely. I have a customer that runs
>> Oracle. When they have moderate traffic they experience a failover event
>> between the Master/Slave. And it appears to come from an inability to
>> access the lock in time causing the slave to take over. When they first
>> came to us, we wondered why they wanted to do this as well.
>>
>> Vince
>>
>> On 7/12/21, 7:56 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote:
>>
>>     To confirm, are you saying that you're trying to use one Oracle
>> database
>>     for message storage and a different Oracle database for locking?
>>
>>     If so, would you mind explaining why you're not just using a single
>>     database for both purposes? I have no idea if the configuration I
>> think
>>     you're describing is possible in the current implementation, but I
>> could
>>     imagine someone saying that there was no need to support it because
>> no one
>>     would ever use it since they'd never want multiple SQL databases vs.
>> using
>>     a single database for both purposes, and I'd like to understand why
>> that
>>     assumption is a bad one.
>>
>>     Tim
>>
>>     On Sun, Jul 11, 2021, 7:23 PM Vince Cox <v...@perforce.com> wrote:
>>
>>     > Using ActiveMQ 5.15.x & 5.16.x I have been unable to get both the
>> locking
>>     > mechanism and the data on 2 unique data sources (using oracle)?
>> Having
>>     > failover issues if they share the connection pool and data source.
>> Is
>>     > anyone aware of how to do this? Is this something ActiveMQ should
>> be able
>>     > to do?
>>     >
>>     > Thank you.
>>     >
>>     > Vince
>>     >
>>     >
>>     > This e-mail may contain information that is privileged or
>> confidential. If
>>     > you are not the intended recipient, please delete the e-mail and any
>>     > attachments and notify us immediately.
>>     >
>>     >
>>
>>
>>     CAUTION: This email originated from outside of the organization. Do
>> not click on links or open attachments unless you recognize the sender and
>> know the content is safe.
>>
>>
>> This e-mail may contain information that is privileged or confidential.
>> If you are not the intended recipient, please delete the e-mail and any
>> attachments and notify us immediately.
>>
>>

Reply via email to