[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] JdbcQueuePlugin won't load
Michael Atighetchi wrote:
I had the same problem: some hours of struggle but at the end it was
worth it ;)
thanks for your help. I got my setup working with a postgres 7.2
database. I dropped looking into support for mysql, as I will
eventually move to Oracle 9i (haven't figured out how to install the
oracle db yet ... ugh :(
It seems strange. The concept is that there is a set of available tables
(one per queue). Additionally there is a table keeping track of the
tables which are currently used and another which contains the tables
which are not associated to a queue (the free tables).
The configuration options I'm using are:
On to the next issue: I see that new tables get created every time
a message is published. Since all the messages really correspond to a
single queue, they should just be stored as multiple lines within the
same table. Is there a way to specify the queue name upon publishing
new messages ?
Are you always publishing with the same oid ? In that case it should
always put the messages in the same table since there is one topic store
and one history queue per oid. On the other hand, if your oid is always
a new one, then a new queue is created each time. There is also one
callback queue per subscriber.
I just finished testing the alternative design
(JdbcQueueCommonTablePlugin) on Oracle (postgres was already tested). It
is a simpler design and worth looking at if large amount of tables is
The requirements are updated and the xmlBlaster.properties.template is
updated too and configured per default with this newer approach.
On Wed, Feb 26, 2003 at 10:24:58AM +0100, Marcel Ruff wrote:
I noticed a warning about useTopic=false (although I don't set it that
way in the property file). After looking at the template property
files supplied with xmlblaster, I added the following entries
Probably you should prefer CACHE over JDBC:
The CACHE implementation uses JDBC internally.
Using JDBC directly you loose all performance
benefits of the cache and it is not safer.
These lines will disappear as soon as we
deliver a native persistence with xmlBlaster again.
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964