RE: [Arch4j-developers] ID Generator

[Chuck L. <chu...@po...>]

For the most part, I think Dave is right, but ... 
 
1. If several applications/systems are inserting rows into the database
and generating overlapping keys, then multiple hits will be made to the
database every time that an insert is attempted with a duplicate key.
However, this problem can be minimized by programmatically avoiding the
creation of a duplicate key in each application/system.
 
2. Using native database calls instead of SQL Inserts, a row can be
inserted and the auto-generated key returned with only one hit to the
database. I did this at my last job calling  stored procedures for each
insert (I created a little utility to automatically generate a stored
procedure for each object/table). I'm not sure if the current EJB
vendors are that clever, but I suspect that they will be soon if they
are not already--they do go to great lengths to improve performance and
this is a very common problem.
 
I'm not exactly recommending the auto-numbering approach yet, but I do
think it is a solid candidate worth investigating further (although, I
am not promising to actually do the research any time soon). If
double-hits to the database can be avoided easily, then auto-numbering
offers a simple, fast, robust solution.
 
Chuck
 
-----Original Message-----
From: arc...@li...
[mailto:arc...@li...] On Behalf Of
David Colwell
Sent: Friday, March 01, 2002 9:32 AM
To: 'arc...@li... '
Subject: RE: [Arch4j-developers] ID Generator



     Right, I don't know of any databases that don't offer some sort of
auto-number feature.  The problem I see with using these is in keeping
business objects in synch with the data they represent.  The problem
situation arises when storing a newly created business object.  I must
first store the data then query the database to get the primary key it
just set for me so I can update my business object.  The cost is two
hits to the database.  The buffering solution only costs one plus a
fraction based on the buffer size configured for each business object.

Dave 


-----Original Message----- 
From: Chuck Lewin 
To: arc...@li... 
Sent: 2/28/02 11:18 AM 
Subject: RE: [Arch4j-developers] ID Generator 

I believe that most major databases and EJB containers support using 
auto-number fields in the database tables as primary keys for EJBs. This

approach probably would be the most robust in terms of high performance 
and low concurrency issues. However, it only makes sense if it is truly 
a platform independent solution. It may be worth the effort of 
researching how portable this approach is (unless someone already knows 
the answer). 
  
Chuck 
  
-----Original Message----- 
From: arc...@li... 
[mailto:arc...@li...] On Behalf Of 
David Colwell 
Sent: Thursday, February 28, 2002 11:08 AM 
To: ''arc...@li...' ' 
Subject: RE: [Arch4j-developers] ID Generator 



     In the past, we've had luck modelling a unique ID generator against

a table that knows the largest unused number for each of a set of unique

keys.  Our provider would grab the highest unused value for the 
"PERSON_ID" key and increment it in the database by 100, for example. 
It could then serve out 100 unique IDs without the cost of hitting the 
database.  The unique ID table had the following fields: key_name, 
value, buffer_size.  The only cost of losing the server VM that it lived

in was the unserved set of values.  If this was an issue for a given 
table, the buffer_size field could be set to 1. 

Dave 

-----Original Message----- 
From: RefuX Zanzebarr 
To: 'arc...@li...' 
Sent: 2/28/02 10:03 AM 
Subject: [Arch4j-developers] ID Generator 

For the Lunch-o-Matic example I've been working on, I 
created an ID Generator Service for generating Primary 
Key IDs. 

I'm thinking I should probably add it into the main 
Arch4J. 
Here the current interface, how does it look? 

/** Service for generating IDs to be used as primary 
keys for the DB. 
 * @author Jroome 
 */ 
public interface IDGeneratorService { 
    /** Get the next id 
     * @return the next id 
     * @param key Key to be used in generating the 
next id. For example the key could be a table name. 
Thus person table and location table could have the 
same ids as their primary keys. */    
    public IdentifierDomain getID( String key ); 
} 

Ok, I know its a simple interface, but this is an 
opensource project so I figure best to get the dev 
mailing list a little bit more active :) 

__________________________________________________ 
Do You Yahoo!? 
Yahoo! Greetings - Send FREE e-cards for every occasion! 
http://greetings.yahoo.com <http://greetings.yahoo.com>  

_______________________________________________ 
Arch4j-developers mailing list 
Arc...@li... 
https://lists.sourceforge.net/lists/listinfo/arch4j-developers 
<https://lists.sourceforge.net/lists/listinfo/arch4j-developers>