I would like to pass a reference to an I/O stream to an EJB from a class running in the web container. I know this doesn't work with remote EJB's because the reference itself is not available (I guess the idea is that remote EJB's could be on different machines, or at least in a different VM). Do local EJB's run in the same VM as the rest of the application? Does this mean they have access to the heap of the rest of the application? If so, then it seems reasonable to pass a reference.
Maybe this makes no sense and I should move all the code that is now in the EJB into POJO's that run in the web container with the rest of the application, but I thought it would be worth checking into first.
Hi Julian, I think, according to the EJB specs, EJBs are not suppose to perform any IO operation, so you should reconsider your design.
Prakash Dwivedi (SCJP2, SCWCD, SCBCD)
"Failure is not when you fall down, Its only when you don't get up again"
posted 13 years ago
I have read that in this forum before - where in the specification is this constraint mentioned and what is the rational? I have stateful session beans talking JDBC to databases and at one point doing BLOB inserts which certainly has all the trappings of I/O (you open a stream to the BLOB, etc.).
I'm close to dumping the whole EJB implementation anyway, but not being able to I/O wasn't the reason I was thinking of... [ January 30, 2005: Message edited by: Randall Julian ]
The reasons for certain limitations on I/O and thread-manipulation are to maintain portability across application servers. But note that the prohibition is not "no I/O" but rather "no opening a ServerSockets for listening for connections." You are allowed to open a Socket to a server and perform I/O on a stream. As you point out, JDBC does this.
Since local interfaces require that you're within the same EAR and thus the same JVM, you should be able to safely pass in a stream. There is no serialization (which would bork your stream) occurring when you make calls through local interfaces.