Michael Atighetchi wrote:
Marcel, Michele,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:
ProtocolPlugin[JDBC][1.0]=org.xmlBlaster.protocol.jdbc.JdbcDriver CbProtocolPlugin[JDBC][1.0]=org.xmlBlaster.protocol.jdbc.CallbackJdbcDriver persistence/defaultPlugin=CACHE,1.0 queue/defaultPlugin=CACHE,1.0 useTopicStore=true queue.persistent.url=jdbc:postgresql://<...>/test cb.queue.persistent.url=jdbc:postgresql://<...>/test
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 a problem.
The requirements are updated and the xmlBlaster.properties.template is updated too and configured per default with this newer approach.
Cheers Michele
Michael
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
persistence/defaultPlugin=JDBC,1.0 queue/defaultPlugin=JDBC,1.0 useTopicStore=true
Probably you should prefer CACHE over JDBC:
persistence/defaultPlugin=CACHE,1.0 queue/defaultPlugin=CACHE,1.0 useTopicStore=true
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.
regards
Marcel
-- Michele Laghi mailto:[EMAIL PROTECTED] tel. +46 8 7492952 / mob. +46 70 4103964 http://www.geocities.com/laghi2000 http://www.xmlBlaster.org
