Discussions

General J2EE: Fake entity bean or Singleton?

  1. Fake entity bean or Singleton? (6 messages)

    I have bunch of rows in a table that is mostly static and the number of rows is in the order of 100. I am considering two options to cache them.

    1) Have a SLSB and a singleton cache behind it. I have no clustering. When a table write operation happens, the singleton is kept synchronized with the changes.

    2)Have a fake BMP entity bean that will contain a collection of all the table rows. There will be only one instance of this entity bean.

    If you have any thoughts on the pros and cons of the two approaches, please let me know.

    Pranab

    Threaded Messages (6)

  2. Fake entity bean or Singleton?[ Go to top ]

    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.

    Gal
  3. Fake entity bean or Singleton?[ Go to top ]

    Thanks for your response. For the entity bean solution, I meant to use commit option A, so that there will be one instance only. I will take a look at the thread you suggested.

    Pranab
  4. Fake entity bean or Singleton?[ Go to top ]

    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.

    Gal
  5. Fake entity bean or Singleton?[ Go to top ]

    Depends on the AppServer. With JBOSS, which is what I am using, you can choose the commit option in the deployment descriptor.

    Pranab
  6. Fake entity bean or Singleton?[ Go to top ]

    As I said, some do allow you to choose. But why lock yourself with vendor-specific features?

    Gal
  7. Fake entity bean or Singleton?[ Go to top ]

    Gal,
    Thanks for your response. I will probably be biased against an App Server that does not allow me to set the commit option. In my opinion, a configurable commit option is a very important feature.

    For complex business objects, I use commit option A for entity beans based on agregate pattern and dependent value objects, essentially leveraging the caching feature of the container.

    Pranab