db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: Working with BasePeer extensions
Date Wed, 04 Feb 2009 11:57:24 GMT
> 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

Any comments and disagreements to this personal opinion are certainly 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message