on 4/26/00 11:32 AM, Gunnar R|nning <[EMAIL PROTECTED]> wrote:
> Do all databases support table level locking ? I'm thinking about
> scalability issues also when it comes to running multiple instances of the
> application.
All the ones that I care about...Oracle/MySQL/Postgres.
We have abstracted support for this within the Turbine connection pool to
case for it (ie: the undocumented methods).
> I'm sure they are working fine the databases you are using them for, but I
> don't think you kind claim they are total abstraction of the database
> interface. Take the method getIdSqlForAutoIncrement() in the DB
> interface. Since the method is not documented I must assume that is used to
> get id generated for your last insert. For Sybase and SQL Server this will
> not work because you would need to this in the same session(connection) as
> the insert was done in. I can't see how this works for MySQL either if you
> have concurrency involved.
Sybase/SQLServer (they are essentially the same) are two very f*cked up
databases with bad JDBC drivers that don't fully implement the JDBC spec.
:-(
What do you expect?
The solution here is to switch to a SQL database that actually supports the
specifications that you require.
> I'm sorry I overlooked the prefetching of IDs. That does indeed improve the
> scalability - it doesn't change my attitude though;
[snip]
> instead of trying to be clever and
> reinvent the wheel.
:-)
It isn't about re-inventing the wheel. We didn't do that at all. We
implemented Scott Ambler's recommendations in his white papers. He is a
known expert in this field.
:-)
It is also about implementing something that works transparently across
multiple databases. JDBC was about doing this, but it only went so far. We
have taken it to the next level.
:-)
> I think it is better to
> use mechanism already in the database
:-)
You are 100% right. That is why we offer solutions to both cases with
Turbine. We have a solution for using sequences in Oracle and AUTOINSERT in
MySQL. You are free to add solutions for other databases as well.
My argument against doing this is that now your code won't be as easily
portable and you have to do all sorts of checking in it to case for which
methodology that you want to use if you want to keep your code easily
portable to other databases.
By using the IDBroker...it is transparent.
:-)
> You might also want to have other applications working
> against the database and funny id generation like this makes it harder to
> write those applications.
:-)
Ug. No it doesn't make it any harder. You just simply need to use the
IDBroker across all of those applications. If you are using another
language, it is simple to re-implement the IDBroker in another language. You
are making the query against a single database table and doing a lock on a
table. It isn't anything overly complex.
:-)
> If I were to change the API it would probably break a lot of existing code,
> I don't know if that is something you want at this time ?
All you are doing is outputting an ID that is a long instead of an int. Even
if that breaks some code, I think that it is worth it and we have been
waiting for someone to submit this patch anyway. Again, your argument
doesn't hold up. :-)
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
