I have reworked quite a bit of stuff related to keys for persistent objects.
1. I changed the attribute for id in BaseObject to an Object. I have left
getId() as returning an int, but this should probably be changed eventually.
I also left the setId(int) but added a setId(Object) method. The main side
effect of this is that I had to change the User interface to include the
setId(Object) method. But it should not be too much effort to alter User
implementations.
2. BasePeer:
I eliminated or moved some methods that I am pretty sure no one was using
directly (even though they were public), so that BasePeer's doInsert is much
easier to follow. The idea now is that you specify whether you are using
sequences, auto-increment, IDBroker, or None method to generate ids for
inserts when you are setting up the TableMap for that table. When inserting
a row, BasePeer calls the appropriate methods to get the id.
Also in BasePeer, I changed the transaction methods to use the jdbc methods
for starting, committing, and rollback.
3. IDBroker:
I moved some of the methods related to generating keys from BasePeer to
here, since this classes purpose is handing out keys. I made the default
key object a BigDecimal to account for large keys and there are convenience
method to convert to int or long. The IDBroker is no longer a singleton.
When adding tables to a DatabaseMap, the TableMap for an ID_TABLE should be
added (if one exists) with the setIdTable() method. If this is done, an
IDBroker is assigned to the DatabaseMap which can be accessed with the
getIDBroker() method.
If transactions are supported by the database, IDBroker uses one when
retrieving keys from the ID_TABLE. Hopefully this prevents duplicate keys,
if multiple IDBrokers are accessing the same ID_TABLE, but it will have to
be tested. Since this transaction is expensive, IDBroker spawns a thread
that checks periodically (every 15 minutes) to see if it should grab more
keys, hopefully before they are needed. If a key is needed and IDBroker has
run out, it goes ahead and grabs more at that time and tries to compensate
for the increased load, so that it does not happen again. It might be good
to add some relaxation of the amount of keys grabbed at one time if load
falls again, but at least IDBroker will not grab more keys if load drops to
the point where only a small percentage of keys held by IDBroker have been
used. This code could probably be made more robust.
I am going to start checking in these code changes. I have tested them some
and they appear to be working, but further testing is needed. So please
grab the changes and let me know of problems asap.
Hopefully, I have not broken anyone's app too much. But I really wanted to
clean up the way BasePeer handles the keys on inserts. This did not happen
earlier, because I thought we would be switching to using OPL as the default
persistence mechanism. (And as George says, we should try to implement the
hooks to other persistence layers.) But since the Peer method was being
used more and more, and being improved by others I thought it better to make
these changes now.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
