> We encountered a problem while using idbroker with more than one JVM. We
> needed to add a behavior for synchronizing the different JVMs when they
> receive the same id "block" from the database, for that a common code
> was needed. So instead of modifying the Torque code, the cleanest
> solution we found to achieve this goal was to do the following things:
> 1. Create a new BasePeer class of our own, with the required algorithms
> in doInsert.
> 2. Modify the schema xml and add a basePeer property pointing to the new
> BasePeer class.
> 3. Create a torque-gen-extension.jar file with one file: "om/Peer.vm"
> with the modified lines:
> 3.1 Wherever there was a direct reference to "BasePeer" in Peer.jm,
> it was replaced by "${table.BasePeer}", e.g.
> return BasePeer.doInsert(criteria, con); >> return
> ${table.BasePeer}.doInsert(criteria, con);
> 4. Regenerate Base... and Base...Peer files using the ant-script.
>
> [REMARK: The common code currently just catches the double second id
> assignment and asks for a new id. This is not yet a smart notification.
> The best thing I would have liked to do was to ask idbroker for a new
> "block" of IDs, but this currently is unavailable. The only option is to
> ask for MAX_INT ids (which will definitely switch to the next block),
> but the next call will ask for yet another block which leads to increase
> in QUANTITY, and upon several of those, the value of QUANTITY is fairly
> huge].
>
> I wanted to know if there are any suggestions / comments for this. And
> if there are no big no-nos, is it possible to integrate this new
> behavior in a next version of Torque (in torque-gen-X.X.X.jar)?
Personally I consider IdBroker as a solution of the past when databases
did not have good id generation support. All the databases I have come
over so far (oracle, postgreql, mysql, firebird, derby) have a decent id
generation of their own. Using the database to generate ids solves the
problem which you are trying to resolve in the IdBroker. Configuration is
also easy, just use defaultIdMethod="native" in the schema and regenerate
the database (of course, migration is a bit more difficult).
>From the users list I get the impression that a lot of people (still ???)
use idBroker; I do not know a good reason for this except that they are
unwilling to migrate (one reason could be that idBroker is still used in
the tutorial; we should change this).
Nevertheless I'd be -0.1 for integrating new complexity in the id broker
in the main Torque distribution, unless an other committer feels this is
necessary and is willing to support this.
Don't get me wrong, I am not saying that it was not the right solution for
you, and maybe we should consider putting this on sourceforge
.net/projects/torque-addons/
Any comments and disagreements to this personal opinion are certainly
welcome.
Thomas
