jon * <[EMAIL PROTECTED]> writes:
>
> Updates don't cause a table locking issue. Inserts do.
Thats right and you can also say that an insert is an update of the
content. That is what I meant;-)
>
> Also, this is something that you can tune by simply increasing the size of
> the block of numbers you can get. So, if you know that you are going to be
> doing a lot of inserts, then simply increase that number and then lower it
> when you are done. If you are doing 100 inserts, grab a block of 100
> numbers. It is as simple as that.
>
> Your statement doesn't hold up at all.
Do all databases support table level locking ? I'm thinking about
scalability issues also when it comes to running multiple instances of the
application.
>
> If you look at the Peer stuff in Turbine, we already have that API ALSO
> IMPLEMENTED AND WORKING!
>
> > I think the DB interface in Turbine would be a good place to add such an
> > API. I see that there already are couple of undocumented methods there that
> > are related.
>
> That is because they are already used for the BasePeer stuff.
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.
>
> Prove to me that the IDBroker doesn't scale. You are totally wrong that you
> think it doesn't.
I'm sorry I overlooked the prefetching of IDs. That does indeed improve the
scalability - it doesn't change my attitude though; I think it is better to
use mechanism already in the database instead of trying to be clever and
reinvent the wheel. 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.
> > The "long" datatype above should maybe also be something else, so one
> > doesn't put any silly restrictions on precision of an id column. BigDecimal
> > is probably the right datatype for this.
>
> Submit a patch.
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 ?
Regards,
Gunnar
--
--------------------------------------------------------------
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]
