Yea, certainly.
The EJB spec is designed to help ensure portability and allow for "wacky" deployment scenarios. You're correct in that there is certainly no promise where an EJB may start running. You could easily see a scenario where you have a cluster of servers and your EJB could be running on any or all of those servers. Written "correctly", the EJB wouldn't care and should just work.
And I am certainly aware that were we to ever cluster our software, issues such as these queues would certainly rear their ugly head. But, that's not a deployment scenario we're looking at right now, and we'd have all sorts of different issues when/if we go to multiple systems.
I think it's more important to understand why EJB restrictions are in place than it is to follow them blindly, simply because they do encompass a large array of deployment scenarios and configurations. That way you can better work your application and, in theory, work around or even violate the limitations, just knowing full well the potential consequences if you do so.
For example, the java.io limitation:
[quote]
An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
[/quote]
Since you're not supposed to use java.io for files or directories, the spec doesn't make any promises that such a facility is available to you (to EJBs that is). Clearly in a clustered system, writing to the local file system and then having a follow up request ask for the "just written" file, but you happen to be on a different cluster node. That's not going to work.
But, the cruel truth is that folks need and want to operate on files. However, I've yet to see a facility, via JCA or anything else, that abstracts and presents a "filesystem like" service. Something that can work on a local filesystem, perhaps transparently over WEBDAV for remote systems, who knows.
Some mechanism may exist, someone may have written one somewhere, but I haven't seen one (and I admittedly haven't looked very hard for one). However, you'd think for something as common and useful as file I/O, in a domain as large as JEE, and the fact that we "can't use it" yet there isn't some common alternative. Not shipped with Glassfish, not available from Apache or some other group. I find it rather telling that such an alternative isn't that popular in the EJB space.
So, I don't take the limitations with a grain of salt, and say "nah, don't worry about it", rather I try my best to live within the "letter" of the law, while understanding the "spirit" of law in the first place, so when I violate it I'll have something noted to watch out for when we deploy to new environments.
[Message sent by forum member 'whartung']
http://forums.java.net/jive/thread.jspa?messageID=480311