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,
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.