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

Re: [xmlblaster-devel] Fixes...



Michele Laghi wrote:
I implemented this change.

Cheers.

Note that there is a difference in the
exception handling from what you suggested.

Hmmm... Thats why I threw it back in your court. I paid little attention to the change in exception handling other than to make it compile.


I tested it with oracle
hsqldb and postgres (all without ldbc) and they all worked fine.


Choice... Looks like it is all go then.

I will be running xmlBlaster with MySQL from now on...
I am not sure whether it is worth while taking it any further.
At least now if someone comes along wanting to use an unsupported database xmlb has an alternative and I am sure the MySQL support will be picked up by others. A lot of machines (web servers with php) run just MySQL now days with postgres being an alternative in some cases.
If you are running any number of php sites you are most certainly going to be running MySQL.


The changes are on the development branch, so what I suggest is that you go to another directory (or you delete your $XMLBLASTER_HOME), and checkout with the following command:

checkout -r DEV_085 xmlBlaster

I think your internet connection is a lot faster than mine... :)
I keep backup copies of the main and devel branches and revert back to the main branch and then do a merge from the devel branch after ensuring that my copy of the main branch is up to date.


I also work from a different machine than the one I use cvs from...
In other words the only time I modify my main copy of the repository
is when I copy a file that is to be updated from my devel machine.

I like to try and keep as much discipline as possible hence the reason for my reluctance to commit to the devel branch... I know that the xml that I loaded yesterday went were it is not supposed to... I think this will cause an automatic rebuild.

I think I better set up a cvs server here and do some more experimenting to figure out how this gui works.


you can find addional information on cvs on

http://www.xmlblaster.org/xmlBlaster/doc/howto/README.cvs


Yep

Could you please run the testsuite with ldbc + mySQL to see if it works ?


Will do.

Thanks and regards

Peter


Michele


Peter Bennett wrote:

Greetings Michele...

I would if I could however I am not an expert with cvs and the devel branch is got me stumped.

I am not sure if I submit anything using gcvs that it is going to go to the right place.

I note last time I did it did not go to the right place.

Sorry for my ignorance...

Regards


Michele Laghi wrote:

Hi Peter,
great that it works even with mySql. Could you please connect the code in the development branch ? I think alternative (a) is the better one.


Once you have committed I would run the tests with oracle hsqldb and postgres (without ldbc).

Regards
Michele


Peter Bennett wrote:

Greetings Michele

I now pass all tests with both MySQL and Postgres including Manually
running org.xmlBlaster.test.classtest.queue.JdbcQueueTest.

There are a couple of minor fixes to code that I need....

As follows...

JdbcManagerCommonTable
deleteEntry()

Basically ldbc/MySQL spits the dummy on the prepared statement after a
rollback. ldbc/postgres is fine... Changing the code to use update works
for both. Can you (a) change to this method for all. (b) Change it so
ldbc uses the update method instead of a prepared statement.




// Connection conn = null;
// PreparedStatement st = null;
try {
// String req = "delete from " + this.entriesTableName + " where
queueName=? AND nodeId=? AND dataId=?";
// String req = "update " + this.entriesTableName + " SET
durable='X' where queueName=? AND nodeId=? AND dataId=?";
// conn = this.pool.getConnection();
// st = conn.prepareStatement(req);
// st.setString(1, queueName);
// st.setString(2, nodeId);
// st.setLong(3, uniqueId);
// return st.executeUpdate();
String req = "delete from " + this.entriesTableName + "
where queueName='"+queueName+"' AND nodeId='"+nodeId+"' AND
dataId='"+uniqueId+"'";
return update(req);
}
catch (XmlBlasterException ex) {
throw ex;
}
catch (Throwable ex) {
// if (checkIfDBLoss(conn, getLogId(queueName, nodeId,
"deleteEntry"), ex))
// throw new XmlBlasterException(this.glob,
ErrorCode.RESOURCE_DB_UNAVAILABLE, ME + ".deleteEntry", "", ex);
// else
throw new XmlBlasterException(this.glob,
ErrorCode.RESOURCE_DB_UNKNOWN, ME + ".deleteEntry", "", ex);
}
// finally {
// try {
// if (st != null) st.close();
// }
// catch (Throwable ex) {
// this.log.warn(ME, "deleteEntry: throwable when closing the
connection: " + ex.toString());
// }
// if (conn != null) this.pool.releaseConnection(conn);
// }



JdbcManagerCommonTable getEntriesWithLimit Line 2179

Remove perenthasis for ldbc to pass it properly...
ldbc seems to figure it out... Are the tests extensive enough
to prove this does not break anything. I also note that the method that
calls getEntriesWithLimit is deprecated. ?????

String req = "SELECT * from " + this.entriesTableName + " WHERE
queueName='" + queueName + "' AND nodeId='" + nodeId + "' AND prio > " +
limitPrio + " OR prio = " + limitPrio + " AND dataId < " + limitId + "
ORDER BY prio DESC, dataid ASC";


Here is how I set up my config...

JdbcStorage[ldbcpostgres]=org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin,\

                       url=jdbc:ldbc:postgresql://localhost/test,\
                       user=postgres,\
                       password=,\
                       connectionPoolSize=1,\
                       connectionBusyTimeout=90000,\
                       maxWaitingThreads=300,\
                       tableNamePrefix=XB_,\
                       nodesTableName=NODES,\
                       queuesTableName=QUEUES,\
                       entriesTableName=ENTRIES,\
                       dbAdmin=true,\
              cascadeDeleteSupported=false,\
              nestedBracketsSupported=false,\
              configurationIdentifier=ldbc

JdbcStorage[ldbcmysql]=org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin,\

                     url=jdbc:ldbc:mysql://localhost/xmlb,\
                     user=mysql,\
                     password=secret,\
                     connectionPoolSize=1,\
                     connectionBusyTimeout=90000,\
                     maxWaitingThreads=300,\
                     tableNamePrefix=XB_,\
                     nodesTableName=NODES,\
                     queuesTableName=QUEUES,\
                     entriesTableName=ENTRIES,\
                     dbAdmin=true,\
                cascadeDeleteSupported=false,\
            nestedBracketsSupported=false,\
            configurationIdentifier=ldbc


#StoragePlugin[JDBC][1.0]=${JdbcStorage[ldbcpostgres]} StoragePlugin[JDBC][1.0]=${JdbcStorage[ldbcmysql]}

StoragePlugin[RAM][1.0]=org.xmlBlaster.engine.msgstore.ram.MapPlugin
StoragePlugin[CACHE][1.0]=org.xmlBlaster.engine.msgstore.cache.PersistenceCachePlugin,persistentQueue=JDBC,transientQueue=RAM




persistence/topicStore/defaultPlugin=JDBC,1.0
persistence/msgUnitStore/defaultPlugin=CACHE,1.0
l
#QueuePlugin[JDBC][1.0]=${JdbcStorage[ldbcpostgres]}
QueuePlugin[JDBC][1.0]=${JdbcStorage[ldbcmysql]}

queue/subject/defaultPlugin=CACHE,1.0
queue/history/defaultPlugin=CACHE,1.0
queue/callback/defaultPlugin=CACHE,1.0
useTopicStore=true

plugin/ior/useNameService false

JdbcDriver.drivers=org.ldbc.jdbc.jdbcDriver

JdbcDriver.mapping[ldbc]=string=varchar(128),"longint=decimal(19,0)",int=int,boolean=char(1),blob=blob,pingStatement=Show

All,blobVarName=ablob,keyAttr=not null

Finally I will start on the requirements again...
They need a rework to reflect the integration...
Also the class files for the ldbc plugin could be removed from the
repository now. The ldbc.jar file also needs updating. I will use the
one from the ldbc web site instead of one compiled by me as you suggested.


Then I need to move on to hsqldb and see if it will go with ldbc...

Regards