• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
  • Frits Walraven
  • fred rosenberger
  • salvin francis

reusing PK, prohibition

Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdee y'all,
Can someone explain whether this constraint in the EJB2.0 Spec is real, or have I over-interpreted its intended meaning?
It says, ... it is legal to reuse the primary key of a previously removed entity object. The container may, but is not required to throw the DuplicateKeyException on ... attempt to create an entity object with a duplicate primary key [15].
See section 10.5.3. bullet 3 pp5, page175, also mentioned in 10.5.2 bullet 4 p171, and reiterated page 269.
Here is my problem with this...
I agree and understand that during a single uncommitted CMT Transaction that this constraint is necessary. However, no such constraint is necessary or enforceable after commit or rollback of the transaction.
This means we should be allowed to create an entity with the same primary key that existed in an entity previously removed (in a previously complete transaction, even assuming Containers with optimistic caching).
My motivation for pursuing this issue is not hypothetical. I want to benefit from the UNIQUE property of the primary key while also allowing the underlying database to perform optimizations that are only possible on the primary key. If I, instead, create an EJB Entity with an extra field solely for the purpose of allowing me to "reuse" the Identifying value of a previously removed entity, I then have to (1) double the amount of storage taken up by thousands of these entities, (2) create an additional UNIQUE INDEX in the underlying database to verifiably enforce the uniqueness of my extra identifying field, and (3) generate unique arbitrary primary key values for the EJB Entity solely to circumvent the prohibition of section 10.5.3.
My hope is that you can tell me that the wording of the Specification did not intend to prohibit re-use of primary keys beyond commit and rollback of the transaction.
[By the way, as a former DBA I am well aware of the philosophy of generating unique PKs, and avoiding the use of problem-domain data for PKs. But, in practice, other considerations sometimes prevail.]
Thanks, partner, in advance for your most excellent insights!
[ October 06, 2003: Message edited by: john prieur ]
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can someone comment on my question, please? Much thanks.
Look! I laid an egg! Why does it smell like that? Tiny ad, does this smell weird to you?
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic