Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

EJB 1.1 specification compliance  RSS feed

 
Dave Coombes
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The EJB 1.1 spec states that an EJB "must not use synchronization primitives to synchronize execution of multiple instances". However, I have seen plenty of examples of EJBs using Vector/Hashtable which are, I believe, synchronized.
Similarly the EJBHomeFactory pattern from The Serverside uses a Collections.synchronizedMap() to cache EJBHome references.
Is it okay to lock on an object other than the bean instance itself?
A related question concerns the use of ResourceBundles within EJBs to obtain runtime configuration information from a .properties file? Is this in contravention of the spec with regards to not accessing the file system from an EJB?
Any help with these questions much appreciated.
Dave
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dave Coombes:
The EJB 1.1 spec states that an EJB "must not use synchronization primitives to synchronize execution of multiple instances". However, I have seen plenty of examples of EJBs using Vector/Hashtable which are, I believe, synchronized.
Similarly the EJBHomeFactory pattern from The Serverside uses a Collections.synchronizedMap() to cache EJBHome references.
Is it okay to lock on an object other than the bean instance itself?
A related question concerns the use of ResourceBundles within EJBs to obtain runtime configuration information from a .properties file? Is this in contravention of the spec with regards to not accessing the file system from an EJB?
Any help with these questions much appreciated.
Dave

Yes, these are all OK. The only reason those things are in the spec is to "promote portability" but in fact, you couldn't get any work done without violating them in classes called by EJB's. So go ahead and use Vectors, Hashtables and Properties, and don't worry about it unduly...
Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Probabably about the 3 most important reasons for the restrictions on EJBs are portability, performance, and reliability.
1. Portability, because EJBs, like Java, are supposed to be "write once, run anywhere" - a task that becomes trickier when you're interacting with different server implementations.
2. Performance, because probably the most common client for an EJB is a web app, and web apps run in real time, so they must return results before the user's browser abandons hope.
3. Reliability, because if you start doing the same kinds of services as the container does, you can confuse the state of the whole system. So things done by the container are generally off limits to the EJB itself. Otherwise you could end up with a non-portable solution not only across platforms, but even between platform versions.
I think that the file I/O restriction was mostly a recommendation, though one of its justifications was because an EJB is a subsidiary resource, which should take information from the environment that it lives in, rather than trying to set up as an entity in its own right. Or, more briefly - accept the rules it is given, not make its own rules. Accessing resources is maybe a gray area, since I could justify nationalizing bean-specific error messages and storing them in a resource.
As to synchronization, it's happening undercover all the time, but the main reason EJBs are themselves forbidden to implement synchronized methods is that the remote interface is already synchronized and you could deadlock.
[This message has been edited by Tim Holloway (edited November 07, 2001).]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!