Hi,
It is not the intent of the restrictions to prevent you from performing
operations such as opening sockets. Rather, the intent of the restrictions
is to make the beans more portable. However, the access to these
connections/resources is not disallowed. Rather, you are encouraged to
access them through resource managers rather than directly from the EJB.
When you access a database connection through a datasource you are actually
accessing a resource through a manager. In addition, accessing a CORBA
object is generally not going to be prevented since the socket creation is
going to happen further down in the call stack, i.e., not in the EJB
directly.
-- Jon
-----Original Message-----
From: Mike Red [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 14, 2000 3:32 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB restriction questions
I addition to your 2 question I would also like to ask a couple of questions
on EJB Restrictions :
1) Why is threading within a bean not allowed. Has it has got anything to do
with maintaining transactional integrity ??
2) The other question is that if opening a socket connection not allowed in
EJB, then what about the communication between a EJB and CORBA, they
internally establish socket connections themselves. Is it accepted to have
an EJB Server to a CORBA Client ??
thanks
>From: "Kenneth D. Litwak" <[EMAIL PROTECTED]>
>Reply-To: "Kenneth D. Litwak" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: EJB restriction questions
>Date: Fri, 12 May 2000 11:39:43 -0700
>
> 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".
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
===========================================================================
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".
===========================================================================
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".
