activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: JDBC Persistence
Date Thu, 23 Mar 2006 03:30:30 GMT
Technically a shared database is a possible option for HA; though it
requires using the database for short term persistence (which is
10-20x slower than using the journal) and would also require the
master locking the slave out of the database to avoid concurrency &
deadlocking issues.

The Master/Slave approach is much faster & tends to work better - also
avoiding a single point of failure as you can have 2 replica databases
rather than a single one.

James

On 3/22/06, Jack Humphrey <jackh@google.com> wrote:
> Is it dangerous to use a shared database in a failover scenario --
> e.g. broker 1 is down, broker 2 takes over? Is sharing a DB a proper
> way to get broker 2 to then deliver messages that were pending on
> broker 1?
>
> On 3/22/06, Jonas Lim <jlim@exist.com> wrote:
> > Hi J,
> >
> > Shared database between multiple  brokers is not really supported.  One
> > reason for this is to avoid potential deadlocks that would   occur in this
> > type of configuration.
> >
> >  You can still use the same database server for each broker; just use a
> > different logical databases for each..
> >
> >
> > Regards,
> > Jonas
> >
> > ----- Original Message -----
> > From: "Javier Leyba" <xleyba@gmail.com>
> > To: <activemq-users@geronimo.apache.org>
> > Sent: Wednesday, March 22, 2006 7:02 PM
> > Subject: JDBC Persistence
> >
> >
> > > Hi
> > >
> > > I did tests with two brokers persisting in the same DB and sometimes
> > > saw in log file a message like that:
> > >
> > > 2006-03-22 10:43:39,372 [eckpoint worker] DEBUG JDBCPersistenceAdapter
> > >        - Commit failed: Duplicate entry '223' for key 1
> > > java.sql.BatchUpdateException: Duplicate entry '223' for key 1
> > >        at
> > > com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java:642)
> > >        at
> > > org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:205)
> > >        at
> > > org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:205)
> > >        at
> > > org.apache.activemq.store.jdbc.TransactionContext.executeBatch(TransactionContext.java:92)
> > >        at
> > > org.apache.activemq.store.jdbc.TransactionContext.executeBatch(TransactionContext.java:71)
> > >        at
> > > org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:151)
> > >        at
> > > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:302)
> > >        at
> > > org.apache.activemq.store.journal.JournalPersistenceAdapter.commitTransaction(JournalPersistenceAdapter.java:177)
> > >        at
> > > org.apache.activemq.store.journal.JournalMessageStore$3.execute(JournalMessageStore.java:269)
> > >        at
> > > org.apache.activemq.util.TransactionTemplate.run(TransactionTemplate.java:43)
> > >        at
> > > org.apache.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:237)
> > >        at
> > > org.apache.activemq.store.journal.JournalTopicMessageStore.checkpoint(JournalTopicMessageStore.java:156)
> > >        at
> > > org.apache.activemq.store.journal.JournalPersistenceAdapter$5.call(JournalPersistenceAdapter.java:355)
> > >        at
> > > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
> > >        at
> > > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> > >        at
> > > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> > >        at java.lang.Thread.run(Thread.java:534)
> > >
> > >
> > > I wonder if should I use one DB for each broker or should I add a new
> > > setting to avoid this kind of errors...
> > >
> > >
> > > Thanks in advance
> > >
> > > J
> >
> >
>


--

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message