I certainly wouldn't use the entity bean solution. You can't make sure there will be only one instance of an entity bean. If the App server uses commit options B or C, it will create a seperate instance when a concurrent call comes in. If it uses commit option A, it will block concurrent calls which can lead to performance differences. The only good way an App server can handle this is by implementing read-only transactions. Not all servers do that, and besides, why rely on something that isn't portable?

I advise you to take a look at the "A.C.E. Smart Cache: Speeding Up Data Access" pattern in the patterns section for some good hints. Read through the thread, the author makes some nice clarifications.

What do you mean by saying "I meant to use commit option A"? You can't choose which commit option you use. The App server chooses the commit option. Some may let you request one option or another, but they don't have to, and not all do. So if you want portable code you can't assume a particular commit option.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.