EJB design: Break EJB rules to synch access to non-database object

  1. Currently the EJB Entity Bean tied even to the latest Object Database does not give my application the speed necessary to meet my requirements. (I understand that this will probably be fixed in a few years - but I can't wait! :) ) I even tried Stateless Session Beans with jdbc and Stateless Session Beans with direct object database api calls. The speed is still lacking.

    I would like to create and maintain my own object in memory (serializing it to disk perioidically). Access would be from stateless session beans - readers and writers only. I know I need to perform synchronization operations that traditional (non-EJB) java provides like: wait, notify, and lock of an object. I also know that this breaks the rules of EJB progamming. The application server may have serious heart-burn with such operations.

    Are there any utility methods that application servers provide for such operations? (They must be available to the pure java (ie. Cloudscape) databases!) Should I use an open source application server and dig for such utitlities? Has anyone else run into a similiar problem?

    Thanks in advance for all your input on this matter!

  2. If you are running all the EJBs in a single app server, why don't you implement a Singleton design pattern (if you have just one object to manage) or an object cache of your own (if you have more than one)?

    It's better than resorting to proprietary APIs.
  3. Just hit me! A Singleton or object cache would require synchronization as well...

    You can do it through a Messaging EJB. A message queue with a single producer (the Messaging EJB) can be used to serialize several consumers' (your Session EJBs') access to the resource (your object).

    Needless to say, you need a EJB2.0 container for that.
  4. Java classes used by EJBs can have synchronized methods, so your cache would be okay (otherwise plenty of useful java classes such as Hashtable, Vectors, etc would be useless). The problem is, that you can't gaurantee that your singleton is a singleton. Different clustered VMs or classloaders would have separate copies.

    As for an alternative solution to the original problem, how about this approach: Cache the data in an entity bean and be "smart" in the ejbLoad() and ejbStore() methods. Only hit the db when neccessary, or dirty, or whatever. You might achieve your periodic synchronization with the db in this way. You still can have situations in which there are multiple copies of the EB instance, depending on the type of caching used by the container. This may or may not cause you problems.

    I am shooting from the hip here, so if I am way off base, someone let me know.

  5. Nice point about singletons, that was why I offered it for a single app server config.

    Hashtable and the like objects are generally locked for very short periods time, during an access that could result in a run-condition. Even when running an iterator on some collection; the collection will be protected against updates -- but certainly not locked.

    From what I understand of Lillian's description, Lillian is trying to keep a lock on the object for time indeterminate and that will certainly bring things to a grinding halt. I just cannot imagine how a container would behave when it tries to manage a locked EJB.

    A singleton that can be locked for time indeterminate does not help either. How does a container behave when its active threads go waiting on the same object? The ostrich algorithm, probably. That's not much improvement over locking EJBs, though with great luck and a low work-load, it could actually work.

    The problem is one of serialization of access to the resource, which fits like a glove with the Messaging EJB concept.

    Being smart with ejbLoad and ejbStore is a viable option if you cannot go with the Messaging EJB.