Question about cached service locator pattern posted at sun and

Discussions

EJB design: Question about cached service locator pattern posted at sun and

  1. Hi all j2ee/ejb guru

    The article(http://www.javaworld.com/javaworld/jw-07-2002/jw-0703-service.html)
    posted at javaworld about service locator pattern seemingly go a step further
    than that posted at sun (http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html)
    The overhead of locating ejb home handle / jdbc datasource seems further reduced
    by the virtue of caching previously located ejb home handle, jdbc datasource..etc.
    However, l have a couple of questions about the cached approach.

    1) Seemingly, it stands a quite high chance a cached EJB home handler / datasource
    returned in this fashion may be referenced / invoked by more than one java class instances
    such as ejb bean instances, javabean helper classes at either ejb or web tier.
    l am just concerned about how the cached home handle and datasource returned by
    service locator deal with concurrent calls arriving at the same time.
    l wonder whether jdbc datasource / ejb home handle can handle it in thread-safe manner ?.
    If not so, does it means datasource / ejb home handle should not be cached and returned
    to 1+ class instances

    2) Even it is thread-safe, as you see, the EJB home handle and datasource implementation
    are provided by EJB container and db vendor respectively. Is the assumption about "thread-safe" nature
    dependent on the vendors's implementation ?

    3) Has J2EE/EJB spec explicitly specify the requirement of implementation of
    jdbc datasource / ejb home handle ? Has the spec explicitly specify how should
    they handle concurrent invocations arriving at the same time (it seems that
    it is not a must for jdbc datasource / ejb home handle to be non-reentrant)

    4) Even ejb container is smart enough to deal with concurrent calls arriving at
    datasource / ejb home handle, how does it handle it?
    Will the calls be handled in a serialized manner?
    If so, it sounds a bit inefficient.


    It is highly appreciated some ejb/j2ee veteran can offer their insight in above
    questions / this design pattern

    thx & regards
    dso

    Threaded Messages (14)

  2. You make a good point, a strict reading of the j2ee specs, both 1.1 and 2.0 do not make any reference to the thread safety of the client object implementing the home interface or the datasource.

    It is correct to say that it is application server dependent as to whether these objects are thread safe or not.

    However...

    I've used quite a few application servers now and have yet to come across a large commercial application server that doesn't provide thread safety in these objects. I do tend to code all my lookups using factories of the abstract factory pattern, so I can plug in different factories depending on the application server. When I first started doing this, I also coded up some factories that pooled these objects but I never actually ended up using them.

    Pragmatically it is only sensible to cache, in most j2ee implementations, the biggest performance hits are in retrieving the JNDI Context and looking up the home object.

    In summary, know your app server and if you have to write platform independent code, consider using a pattern allowing pluggable behaviour (Abstract Factory, Strategy).

    Hope this helps,

    Bob B.
  3. Hi Bob b

    First, thank you very much for your response to my questions. After going through your explanation. l still have a few questions. It is very thankful if you can once again give your view points on my below questions.

    As mentioned in your reply, do you mean to use Abstract Factory pattern to instantiate the service locator ?
    If the app server support thread-safe home handle/datasource, a service locator with caching ability is returned. On the other hand, a service locator WITHOUT caching ability is returned ? If l misunderstood your explanation, it is thankful you can elaborate on further.

    Also, l find that the manual of app server rarely specify whether the implementation of home handle / datasource are thread-safe or not. For example, JBoss manual and JDBC manual for Oracle DB do not explicity specify whether those object are thread-safe or not. It seems that it is quite unsecured to assume they are thread-safe. Am l correct ?

    Last but not least, even ejb container is smart enough to deal with concurrent calls arriving at
    datasource / ejb home handle, how does it handle it?
    Will the calls be handled in a serialized manner / parallel manner? Do the manul of most app servers go into such detail. l am just wondering it ?

    thx & regards
    dso
  4. Yes, you are quite right, use an Abstract Factory pattern to get your ServiceLocator - however for non-threadsafe home objects/datasources, you might consider pooling.

    The thread-safety issues are never covered by the manuals - I think that's how they sell consultancy services ;-) - but usually if you fire off a question on one of the application server's support forums (or just use google (groups) to find if the answer already exists) someone will usually be able to tell you.

    How the app server deals with concurrent requests - hmmm... I've never really bothered with that and it does tend to be app server specific. But as I've written server code in the past I can make a best guess:

    Neglecting JNDI and the whole question of whether home interfaces load balance or not - on the server there will be a server socket listening on the port that is specified, when a request comes in, the request is shed to a socket that actually does the work, usually with an associated worker thread and usually these are pooled. Requests are received by the server socket in a serial manner (how networks work), but are shed immediately to worker threads so that they can be processed in a parallel manner.

    If you want to really understand how this all works the java.net package is a good starting point.
  5. Hi Bob b

    Thank you very much for your detailed explanation.
    Do you know how the IPlanet 6.x , JBoss 2.4.4 and Sybase jdbc driver deal with the issue l raised out. Are the EJB home handle/jdbc datasource supplied by above softwares thead-safe ?

    It is highly appreciated if someone can share with me your experience with these software.

    thx & regards
    Danny
  6. Danny,

    Unfortunately I haven't used JBoss before so I don't know about the thread safety of their DataSources and Home interface instances (I can tell you about WebLogic, WebSphere etc.). That really is a question that you need to float in a JBoss forum, I would be extremely surprised if they weren't though.

    I'd be interested to know the answer myself to add to my store of knowledge :-)

    Sorry I can't help you further,

    Bob B.
  7. Hi
      I am wondering if we need datasources/EJB home handles to be thread safe ; cause normally we use them to get to resources/objects like connections/remote references .Do you guys think that if multiple threads access DS/home handles at same time ; it will create problems.An example would be appreciated.
      Thanks
    Tim
  8. If you follow this link to a JavaWorld article you will see one situation where the thread safety of an Home/Datasource client instance becomes important.

    The location and retrieval of an Home/Datasource client instance can be a significant overhead, and it makes sense to retrieve them as rarely as possible. The usual way of doing this is to cache these objects once retrieved and reuse them. Further time (and memory) savings can be made if you only ever need to retrieve one instance and can thereafter safely use it throughout your application, thus thread safety can become an issue.

    Most modern application servers implement thread safety in their Home objects/Datasources. For example WebSphere and WebLogic.

    Some reasons for not caching the remotes are because you cannot guarantee their availability and if you are running in a clustered environment you will find that most load balancing implementations work behind the Home interface objects but not behind the Remote interface objects.
  9. Hi Robert
       I am still not clear as to how threads can create a problem with home/datasources.For example most of the time datasources are used as a factory of connection objects .What can go wrong if two threads try to create a connection at the same time.
      Thanks
    Tim
  10. Hi All

    thanks you very much for you guys' reply to my questions,
    it really help me clarify my understanding in this topic very much. But l still have 3 questions in mind. It is kindly someone can further provide feedback on them

    1) As in those replies, most modern application servers implement thread safety in their Home objects/Datasources. However, how do the home handle/datasource handle the concurrent requests for creating remote object/connect ?
    Are the requests handled in a serialized manner. If so, will it be very ineffective.

    2) If the service locator cache the home handle/datasource,
    it seems to me that methods such as ServiceLocator.getInstance().getHome(String servicehome) / ServiceLocator.getInstance().getDataSource(String name),etc should be declared as "synchronized". EJB bean instance using this service locator will indirectly invoke "synchronized" statement. It seemgingly violate the EJB programming practice which warn developers against controlling thread synchronization on their own.

    3) Lastly, do anyone know whether JBoss's implementation of home object / datasource is thread-safe or not.

    thx & regards
    dso
  11. In reply to your first two questions:

    1/ As long as they are written correctly, concurrent requests to a client home interface instance will run in a broadly parallel manner. There is usually no need to synchronize whole methods and with careful code you don't need to synchronize anything at all. If the 'mutable' variables are method level variables (and thus are part of the threads' own heaps) and the instance variables are not written to by the threads, only read from, then threads can run through an instance completely in parallel.

    2/ Good question, a strict reading of the specs is very clear on the issue of intra-thread communication generally, stating that it is the responsibility of the container vendor. However if the 'synchronized' occurs within classes supplied by the vendor, then you are completely within the specification.
  12. But as asked in Q2, service locator is implemented by us. In order to make service locator cache the retrieved home handle / datasource, this singleton service locator should has an instance variable of Hashmap or hashtable to store those retrieved home handle / datasource. Consequently, methods of service locator such as ServiceLocator.getInstance().getHome(String servicehome) / ServiceLocator.getInstance().getDataSource(String name),etc must be declared as synchronized. As you see, this class, service locator, is NOT provided by container vendor but provided by us. However, it seemgingly violates the EJB programming practice which warn developers against controlling thread synchronization on their own.
    Any comment on this ????
  13. Sorry, I misunderstood your question...

    Yes, if you use the version of the cached service locator pattern that is generic, then you are forced to use a synchronized either directly or indirectly (using a Collection synchronized HashMap). A lot of people do this as a matter of course, but this does break the specification. I do use this pattern as is, but usually only after running proving tests on the app server that I am running it on, or after posting/reading support forum questions.

    One way around this is to use a static initialiser to populate an unsynchronized HashMap with all the home interfaces you have in your application (threadsafe without breaking the spec.), then as long as the home interface instances are thread safe and you do not need to refresh the a home interface instance (can be application and application server specific), you remain within the specification.
  14. Really thanks a million for all folks responded to my questions. Your sincere help have made me better understanding the ejb. Once again, thanks you VERY MUCH !

    regards
    dso
  15. I don't know how much multi-threading code you have written, but a classic anti-pattern in writing a thread safe classes is to have an instance variable that is altered by the threads using a shared instance of the class.

    Say the object was written with an instance variable keeping track of connection state to the server, the first thread comes in sets it to 'awaiting connection', connects and sets it to 'connection achieved'. Thread 2 now starts using the shared instance and sets the instance variable to 'awaiting connection', thread 1 looks at this and gets terminally confused ;-). I know it's a trivial example but the specifications don't say that client Home instances and client Datasouce instances have to be thread safe, so certain implementations could use mutable instance variables and other non-threadsafe constructs. It's often quicker and easier to write non-threadsafe code.

    You're quite right though, there is no reason for server vendors to write non-threadsafe code in these objects and as far as I know none of the current ones do.