[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] JdbcQueuePlugin won't load

Hallo Michael,

Michael Atighetchi wrote:
Marcel, Michele,

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 :(
I had the same problem: some hours of struggle but at the end it was worth it ;)

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 ?

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).

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 a problem.

The requirements are updated and the xmlBlaster.properties.template is updated too and configured per default with this newer approach.

Cheers Michele


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.



Michele Laghi
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964