Re: Generating primary keys
;
try {
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)
ic.lookup(JndiNames.SC_DATASOURCE);
connection = ds.getConnection();
} catch (NamingException ne) {
throw new EJBException(ne);
} catch (SQLException se) {
throw new EJBException(se);
}
return connection;
}
}
ejb-jar.xml
###
entity
descriptionGenerator for Unique IDs/description
display-nameUidGenerator/display-name
ejb-nameUidGenerator/ejb-name
homeorg.shiftctrl.uid.persistence.UidGeneratorHome/home
remoteorg.shiftctrl.uid.persistence.UidGenerator/remote
ejb-classorg.shiftctrl.uid.persistence.UidGeneratorEJB/ejb-class
persistence-typeBean/persistence-type
prim-key-classjava.lang.String/prim-key-class
reentrantFalse/reentrant
resource-ref
descriptiondescription/description
res-ref-namejdbc/DefaultDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
/resource-ref
/entity
container-transaction
method
ejb-nameUidGenerator/ejb-name
method-namegetUid/method-name
/method
trans-attributeRequiresNew/trans-attribute
/container-transaction
--
Joni
[EMAIL PROTECTED]
Jeff Schnitzer wrote:
If you're required to use triggers (or some other database-specific
mechanism) to generate primary keys, someone posted a clever solution to
this list a long time back: use a finder method. Since you control the
SQL issued for a finder method, just add a
Thingie findNew(Type param, Type param);
method and have it create the appropriate row in the SQL before
selecting it out.
BTW, the counter.jar is *not* portable. It relies on pessimistic
concurrency behavior, and as far as I know the only other appserver
which supports this model is WebLogic when not clustered. Even in WL 6,
the default behavior is now optimistic concurrency.
Here's a direct link to Brett's article about sequences (the original
link has moved on to other topics):
http://www.flashline.com/content/mclaughlin/bm050701.jsp?sid=98987171807
8-1066877012-153
http://www.flashline.com/content/mclaughlin/bm050701.jsp?sid=9898717180
78-1066877012-153
This is, I believe, the *only* portable way of generating sequence-type
keys in EJBland. It astounds me that this is the case given that a)
nearly every database offers some sort of facility for generating keys
and b) the EJB container could fake it for the ones that don't.
Considering how common the need to generate primary keys is, I consider
this an grossly unacceptable deficiency in the spec. I'm not normally
prone to believing conspiracy theories, but I have to wonder if the big
RDBMS vendors sitting on the EJB committee (read: Oracle and IBM) are
deliberately trying to keep CMP from becoming too popular. This is just
too wierd.
Jeff Schnitzer
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://www.similarity.com
-Original Message-
From: elephantwalker [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 14, 2001 8:38 AM
To: Orion-Interest
Subject: RE: Generating primary keys
two ways of doing this...
1. map your ejb pk to another ejb. The counter.jar does this. It creates
a long for every beantype. See the faq at www.orionserver.com
http://www.orionserver.com . I think there is something under
http://www.orionsupport.com/articles/ejbuniquecounter.html
http://www.orionsupport.com/articles/ejbuniquecounter.html
http://www.orionsupport.com , also. In your ejbCreate(), get a
reference to the counter.jar, and then ask for the new pk :
long id =
com.evermind.ejb.CounterUtils.getNextID(java:comp/env/ejb/Counter,
mybeanname);
2. See the chain of articles by Brett McGlaughlin at
http://www.flashline.com/content/community.jsp?sid=989854104625-10905805
43-153#brett
http://www.flashline.com/content/community.jsp?sid=989854104625-1090580
543-153#brett http://www.flashline.com . Instead of using an ejb to
generate your pk references, use jdbc and a stateless session bean. In
the end you do the same thing in your ejbCreate():
long id = slsbRemote.getNextID(mybeanname);
And whatever you do, stay away from triggers.
Regards,
the elephantwalker
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sergei Batiuk
Sent: Monday, May 14, 2001 10:08 AM
To: Orion-Interest
Subject: Generating primary keys
Hi mailing list,
I have the following problem: the primary key for my EJB is generated at
the database level ( a trigger ), so I don't want to generate it in the
ejbCreate() method. However, EJB specification says, that the use of the
primary key is a MUST. Does anyone have the solution for this problem?
Any help is greatly appreciated.
Sergei.
Generating primary keys
Hi mailing list, I have the following problem: the primary key for my EJB is generated at the database level ( a trigger ), so I don't want togenerate it in the ejbCreate() method. However, EJB specification says, that the use of the primary key isa MUST. Does anyone have the solution for this problem? Any help is greatly appreciated. Sergei.
RE: Generating primary keys
two
ways of doing this...
1. map
your ejb pk to another ejb. The counter.jar does this. It creates a long for
every "beantype". See the faq at www.orionserver.com. I think there is
something under http://www.orionsupport.com/articles/ejbuniquecounter.html, also. In your ejbCreate(), get a
reference to the counter.jar, and then ask for the new pk :
long id =
com.evermind.ejb.CounterUtils.getNextID("java:comp/env/ejb/Counter",
"mybeanname");
2. See
the chain of articles by Brett McGlaughlin at http://www.flashline.com/content/community.jsp?sid=989854104625-1090580543-153#brett. Instead of using an ejb to generate your
pk references, use jdbc and a stateless session bean. In the end you do the same
thing in your ejbCreate():
long id = slsbRemote.getNextID("mybeanname");
And
whatever you do, stay away from triggers.
Regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sergei
BatiukSent: Monday, May 14, 2001 10:08 AMTo:
Orion-InterestSubject: Generating primary keys
Hi mailing list,
I have the following problem: the primary key for
my EJB is generated at the database level ( a trigger ), so I don't want
togenerate it in the ejbCreate() method. However, EJB specification
says, that the use of the primary key isa MUST. Does anyone have the
solution for this problem?
Any help is greatly
appreciated.
Sergei.
RE: Generating primary keys
If you're required to use triggers (or some other database-specific mechanism) to generate primary keys, someone posted a clever solution to this list a long time back: use a finder method. Since you control the SQL issued for a finder method, just add a Thingie findNew(Type param, Type param); method and have it create the appropriate row in the SQL before selecting it out. BTW, the counter.jar is *not* portable. It relies on pessimistic concurrency behavior, and as far as I know the only other appserver which supports this model is WebLogic when not clustered. Even in WL 6, the default behavior is now optimistic concurrency. Here's a direct link to Brett's article about sequences (the original link has moved on to other topics): http://www.flashline.com/content/mclaughlin/bm050701.jsp?sid=98987171807 8-1066877012-153 http://www.flashline.com/content/mclaughlin/bm050701.jsp?sid=9898717180 78-1066877012-153 This is, I believe, the *only* portable way of generating sequence-type keys in EJBland. It astounds me that this is the case given that a) nearly every database offers some sort of facility for generating keys and b) the EJB container could fake it for the ones that don't. Considering how common the need to generate primary keys is, I consider this an grossly unacceptable deficiency in the spec. I'm not normally prone to believing conspiracy theories, but I have to wonder if the big RDBMS vendors sitting on the EJB committee (read: Oracle and IBM) are deliberately trying to keep CMP from becoming too popular. This is just too wierd. Jeff Schnitzer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.similarity.com -Original Message- From: elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Monday, May 14, 2001 8:38 AM To: Orion-Interest Subject: RE: Generating primary keys two ways of doing this... 1. map your ejb pk to another ejb. The counter.jar does this. It creates a long for every beantype. See the faq at www.orionserver.com http://www.orionserver.com . I think there is something under http://www.orionsupport.com/articles/ejbuniquecounter.html http://www.orionsupport.com/articles/ejbuniquecounter.html http://www.orionsupport.com , also. In your ejbCreate(), get a reference to the counter.jar, and then ask for the new pk : long id = com.evermind.ejb.CounterUtils.getNextID(java:comp/env/ejb/Counter, mybeanname); 2. See the chain of articles by Brett McGlaughlin at http://www.flashline.com/content/community.jsp?sid=989854104625-10905805 43-153#brett http://www.flashline.com/content/community.jsp?sid=989854104625-1090580 543-153#brett http://www.flashline.com . Instead of using an ejb to generate your pk references, use jdbc and a stateless session bean. In the end you do the same thing in your ejbCreate(): long id = slsbRemote.getNextID(mybeanname); And whatever you do, stay away from triggers. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sergei Batiuk Sent: Monday, May 14, 2001 10:08 AM To: Orion-Interest Subject: Generating primary keys Hi mailing list, I have the following problem: the primary key for my EJB is generated at the database level ( a trigger ), so I don't want to generate it in the ejbCreate() method. However, EJB specification says, that the use of the primary key is a MUST. Does anyone have the solution for this problem? Any help is greatly appreciated. Sergei.
Generating primary keys in CMP?
Hello, I'm looking for a way to generate primary keys for my container managed entity beans. For bean managed persistance you would simply use the functions that your DBMS provides, like sequences or auto-increased columns. But how do I do this with CMP beans? In books and example code everyone avoids the subject entirely, with create(int id) as the creation method. A solution I've seen suggested is to use a separate session bean to generate unique integers, but they are generally a mess to implement and use. So what I'm looking for is something better than that. The J2EE servers based on object databases (GemStone/J at least) has an id generator "for free". But it seems this shouldn't be impossible with relational DBMSes. I would guess that it could be done by the CMP container, possibly by using DBMS-dependent plugins for different id generator implementations? Anyway, if this isn't possible I'm looking for a good implementation of a session bean based id generator... /Anders A n d e r s B e n g t s s o n [EMAIL PROTECTED] http://www.natakademin.se/
Re: Generating primary keys in CMP?
For bean managed persistance you would simply use the functions that your DBMS provides, like sequences or auto-increased columns. But how do I do this with CMP beans? In books and example code everyone avoids the subject entirely, with create(int id) as the creation method. Annoyingly enough, most EJB resources tend to avoid this subject. Wish they wouldn't. A solution I've seen suggested is to use a separate session bean to generate unique integers, but they are generally a mess to implement and use. So what I'm looking for is something better than that. There are 2 main approaches 2 generating IDs. Firstly you could use the internal features of your database - many db's support SEQUENCES. This solution seems fairly simple and elegant but using a db specific approach can cause problems if you later decide to switch databases. The preferred way to generate ID's is using a session bean and an entity bean. The entity uses a reference to the table or bean name as a primary key, and has a second field which stores the next id to use for that table. The session bean is used as a wrapper around the entity to easily request the next id per table. In fact, updating the entity every time a new id is needed can be quite a cumbersome and inefficient process, so a HIGH/LOW strategy is more appropriate. Briefly, this is where the session bean is stateful and instead of requesting and incrementing the entity each time an id is required, a block of id's (eg: 20) are requested from the entity (which then increments the count by that number) and the session counts out each id until the block runs out, at which point it requests another block. Multiple sessions can be used and each session will count with a seperate block. Concurrent access can be handled by catching transaction exceptions and trying again. The drawbacks to this is that the id's in the db table are not guaranteed to be in order and there may be some gaps if a session is destroyed before it uses all of it's block of ids. The main advantage is that you will not be tied in to any particular db. There's a nice little paper that may be of use that describes this method (although it has nothing to do with Java or EJB's): http://www.ambysoft.com/mappingObjects.html -Joe Walnes
