I have two questions about the coding restrictions on EJBs.
1. You're not supposed to do anything that requires a class from java.io.
Yet, you can make your own database connections and do SQL or whatever else your
JDBC driver happens to support, like IMS DL/1 calls). I can understand that
donga long I/O would be bad if a bean needed to be passivated. Note: I don't
know what rules a container uses to decide when to passivate a bean. I presume
it has to do with how long ago a client called it, not whether it is dong work
itself. Is that right? In any case, I fail to see how something from java.io
differs materially from something in java.sql. Both do I/O, and db calls also
create sockets under the covers. Why is it okay to make database calls, but not
okay to do file oI/O? Why is waiting for a long write to a DataOutputStream any
different from a long select call?
2. I rpesume the reason you shouldn't use static data memers is because they
can't be passiviated. Object serializtion only uses defaults for static dat.
What about static methods? Are they also unacceptable? If so, does it have to
do with how to share a copy of a method whose class may no longer be in memory?
As an aside, I have a vendor question. Are most app/EJB servers out there
running with eerything in one JVM, servlet engine, ejb server, the whole nine
yards, or does every thing, the servlet engine, the EJB server, and so forth,
get its own JVM? SInce JVMs are CPU-intensive, are there any a app/EJB servers
out there that allow you to start the servlet enigne on one host and the ejb
server on another host, but controlled from one central spot (as opposed to
haveing two complete copies of the whole product, one on each host)? Thanks.
Ken
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
