• 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 ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Recommendation on design approach

 
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,

In our project, the existing design is as follows :

1) When an Entity bean is created, we are assigning the primary key of that entity as "0" like,

someHome.create(0,........);
2) But there is a database trigger defined, which would assign a primary key for NEW or UPDATE operation.

This design worked fine, because the calling application is not bothered about primary key.


Now we have a production problem, where in we need to act upon the primary key. We could easily fix this, by generating the primary key upfront and assign it instead having the trigger generate it for us. But this will impact so many other interfaces. One more thing, which is very important here to understand is, the trigger takes the primary key of the latest entity persisted and increments by 1 to generate the next primary key. I was proposing to query the table to determine the latest primary key and increment it just like trigger doing and use that new primary key to persist the next entity. But there was a question concerning the following of ACID properties here. How can we ensure that before a new key is identified and assigned, there was not another request for peristing another entity and we mix up the keys. I'm not sure about the issues I can get into with this, but some how that proposal was denied.

Can I synchronize the code using block synchronization in session bean, where the entity beans are persisted around the primary key generation and persistance of the entity bean.

Some thing like


Any suggestions here.

Thanks
Ravi CKota
 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Schandha Ravi wrote:Can I synchronize the code using block synchronization in session bean, where the entity beans are persisted around the primary key generation and persistance of the entity bean.


No, an ejb must not use thread synchronization (except it's an EJB3.1-singleton bean with bean-managed concurrency).

Schandha Ravi wrote:I was proposing to query the table to determine the latest primary key and increment it just like trigger doing and use that new primary key to persist the next entity. But there was a question concerning the following of ACID properties here. How can we ensure that before a new key is identified and assigned, there was not another request for peristing another entity and we mix up the keys.


If you're using optimistic looking it's always possible that another request inserted an entity just with the same key that you figured out, too.

But this shouldn't be a real issue: In a project we had a messaging system that logged each in- and out-mesage. Primary key was the timestamp. If an insertion failed with a duplicate key exception the timestamp was incremented by one and we repeated the insert, and so on. The system processed several million messages per day and was quite performant and stable.

The only issue with your proposal I see is: Each insert results in two db operations:

1. selection of the lastest primary key
2. insert

If there are many inserts and you need high performance then this might require more elaborate solutions. For example the latest primary key could be saved in a separate small table that could easily be cached by the database (this corresponds to the GenerationType.TABLE approach for generated values in JPA).
 
Schandha Ravi
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply. I have couple of more questions around this topic.


Schandha Ravi wrote:
Can I synchronize the code using block synchronization in session bean, where the entity beans are persisted around the primary key generation and persistance of the entity bean.

No, an ejb must not use thread synchronization (except it's an EJB3.1-singleton bean with bean-managed concurrency).



Why the thread synchronization not permitted in an ejb. I'm sure it would not throw me any compiler errors. But what potential problems could we face, if used. Would this intervene with container and result into undesirable situation. What changes came in for allowing this in EJB3.1

Coming to my question posted earlier, I'm thinking of another approach for gaining the control of primary key. Since, all I needed was to send back the right primary key to the calling application, can't I try retrieving it in ejbPostCreate(). Would that be inviting the trouble ?
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Schandha Ravi wrote:Why the thread synchronization not permitted in an ejb. I'm sure it would not throw me any compiler errors. But what potential problems could we face, if used. Would this intervene with container and result into undesirable situation.

That's a programming restriction due to the ejb spec (see for example EJB 3.1 spec, section 21.2.2). If you are using your own thread handling in a session or mesage driven bean then the behavoir of the system is undefined.

Schandha Ravi wrote:What changes came in for allowing this in EJB3.1

It's not allowed in general, but only for the newly introduced singleton beans:

One of the serious limitations prior to EJB 3.1 was the missing of a standardized method for sharing state between beans. Now that's encompassed by singleton beans. As the name says there exists only one instance of a singleton bean in a JEE application. Therefore there could be concurrent requests on such a bean. Similar to the transaction type (container managed / bean managed) there are two types of concurrency management: container managed concurrency / bean managed concurrency. Bean managed concurrency relies on the usual Java synchronized semantics for synchronizing the business methods. That's why singleton beans with bean managed concurrency are excluded from the thread synchronization restriction stated above.

Schandha Ravi wrote:Since, all I needed was to send back the right primary key to the calling application, can't I try retrieving it in ejbPostCreate().

If getPrimaryKey returns the generated key in ejbPostCreate then this should be manageable.
 
Schandha Ravi
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Ralph... I have not studied much on EJBs and espicially after EJB 2.0. It seems I'm far behind in race :-). Got to get some hands on with latest versions.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic