Re: IdGenerator change

[Leif Mortenson <le...@tanukisoftware.com>]

Sasvata,
    Supper late responding to this.  But finally got around to fixing this.
The Id generator should now work with any database.  It uses a retry method
of allocating tables making sure that no other processes have updated the
table at the same time.
    This method should work on databases which do not support table locking
or transactions.  I was also able to get rid of the ugly special MySQL code.

    I have only tested this with MySQL and HSQLDB so far however.  So if
anyone could run the tests with another DB, I would appreciate it.

You will need to add the following properties to the root ant.properties 
file to
enable JDBC tests:
# --- Enable JDBC Tests ---
test.jdbc=true
test.jdbc.driver=com.mysql.jdbc.Driver
test.jdbc.url=jdbc:mysql://localhost/test
test.jdbc.user=<user>
test.jdbc.password=<password>

See the ant.properties.sample file.

Cheers,
Leif

Sasvata (Shash) Chatterjee wrote:

>Actually, it turns out that it is not that HsqlDB does not support
>transactions, looks like the Hsqldb-1.7.0 JDBC driver does not support the
>setTransactionIsolation() function.  Plus, it looks like the "LOCK TABLE"
>syntax used in TableIdGenerator is proprietary for MySQL.
>
>So, I guess, the real question is how to lock HsqlDB in an elegant fashion,
>without adding yet another function for Hsqldb in IdGenerator?
>
>----- Original Message -----
>From: "Sasvata (Shash) Chatterjee" <sa...@hotmail.com>
>To: <av...@jakarta.apache.org>
>Sent: Tuesday, July 16, 2002 9:18 PM
>Subject: IdGenerator change
>
>
>  
>
>>Hi!
>>
>>We are trying to use HsqlDB with Excalibur-Datasource's IdGenerator.  The
>>problem I ran into was that looks like TableIdGenerator assumes that the
>>backend DB is transaction capable, unless it is MySQL.  I wanted to change
>>AbstractDataSourceIdGenerator.configure to use a configuration item
>>"use-transaction" to allow a more generic way of specifying this, instead
>>    
>>
>of
>  
>
>>setting/using m_dbType for MySQL/not-MySQL.
>>
>>Are there any problems with this approach?
>>
>>Thanks,
>>Shash
>>
>>--
>>To unsubscribe, e-mail:
>>    
>>
><ma...@jakarta.apache.org>
>  
>
>>For additional commands, e-mail:
>>    
>>
><ma...@jakarta.apache.org>
>  
>
>>    
>>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>