I looked in the list, but these restrictions seemed to apply to the EJB Bean
itself.  I understand the container-managed instance pooling imposes this
restriction somehow, although I dont understand exactly why.

In particular, I'm wondering if static data can be moved into a utility
class which is created by the EJB bean code, and therefore get around the
static restriction.


Purpose:  cache object handle JNDI lookups on bean home interfaces,
transaction mgr, etc.
          Since I know these will never change, I'd like to find it once and
hold onto it.
          I have a number of EJBs which will need to call each other.
Rather than
          looking up the home interface via JNDI each time I need to call
another bean,
          I'd like to cache it.


Something like:
   class JNDICache {
      private static Context initialContext_;
      private static UserTransaction userTransaction_;

      static public Context getInitialContext( ) {
        if ( initialContext_ == null )
        {
          Context initialContext= null;
          Properties env = System.getProperties();
          env.put("java.naming.factory.initial",
"com.sun.jndi.rmi.registry.RegistryContextFactory");

          try {
            initialContext = new InitialContext(env);
          } catch (Exception e) {
            System.exit(2);
          }
          initialContext_= initialContext;
        }
        return initialContext_;
      }


      public UserTransaction getUserTransaction( ) {
        if ( userTransaction_ == null )
        {
          UserTransaction utx= null;
          try {
            Context initialContext = getInitialContext();
            utx =
(UserTransaction)initialContext.lookup("javax.transaction.UserTransaction");
          } catch (Exception e) {
            System.exit(2);
          }
          userTransaction_= utx;
        }
        return userTransaction_;
      }

      public EJBHome getEJBHome( String beanName ) {
         // code to return handle to EJBHome for a given name
         // via caching, using JNDI only for first call.
      }
   }

  CODE IN EJB:
  -----------
   JNDICache jc= new JNDICache();
   EJBHome eh= jc.getEJBHome( "BankAccount" );   // nonstatic method, static
data

   EJBObject eo= eh.findByPrimaryKey( ... );

   -OR-

   EJBHome eh= JNDICache.getEJBHome( "BankAccount" );  // static method,
static data
   EJBObject eo= eh.findByPrimaryKey( ... );




Thanks
-Steve Roth, [EMAIL PROTECTED]



> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Tuesday, October 26, 1999 9:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB Restrictions-- threads, io
>
>
> Hey
>
> Steve Roth wrote:
> > I forgot to mention the most important restriction I've seen-- no static
> > methods/data members
> >
> > Can U have static methods/data members?
>
> No. This is strictly fobidden, for good reasons. See archive for
> details: http://archives.java.sun.com/archives/ejb-interest.html
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ==================================================================
> =========
> 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".

Reply via email to