> > > >
> > > > private static DataSource ds = null;
> > > > private static InitialContext ic = null;
> > > >
> > > > private void init() {
> > > > if (ic == null)
> > > > initHomes();
> > > > }
> > > > private static synchronized void initHomes() {
> > > > if (ic == null) {
> > > > ic = new InitialContext();
> > > > ds = (DataSource) ic.lookup("someDataSource);
> > > > }
> > > > }
> > > >
> > >
> > > Sorry but I didn't understood your example, unless you'd
> referred to
> > > ordinary classes, right? In stateless EJB there is no
> such thing as
> > > init() method for initialization. Or am I wrong?
> >
> > Sorry, my mistake. This is for a stateless session bean.
> You'd have to
> > include a call to init() in every business method invocation:
> >
> > public void methodA() {
> > init();
> > //rest of code goes here.
> > }
>
> Just one more thing, the "synchronized" keyword doesn't raise
> problems in the EJBs or since it's in a "static" method there
> is no problem?
>
> Actually, you should not use either static or synchronized in
> your ejb unless you´re using a final static field. According
> to the specifications this is to eliminate problems if your
> ejb container runs on more than 1 JVM (thanks to IBM I
> guess). So if you´re certain about what you´re doing (just 1
> jvm for most servers) there should not be much of a problem
> using either static or synchronized.
>
As Sven(or sven, sorry) points out, static and synchronized should be
used with care. I use static to insure that at most one cached copy of
the DataSource is kept per JVM. Since session bean instances can be GCd,
storing the DataSource locally on each instance may yield no performance
gains on some configurations. I use synchronized to insure that
initializations aren't duplicated. You can find out more about this
topic if you google for Singleton Pattern and "Why Double Checking is
Broken". Since synchronization is expensive, I use the init() method to
test for the condition first and try to avoid *some* of the calls to
initHomes().
Finally, since I'm not relying on static nor synchronized to effectively
and without exception cache a single instance of DataSource across the
cluster, I'm not incurring in any of the scenarios for which static and
synchronized are "prohibited" by the spec.
Pedro, this isn't a complete example and you should test it further, but
it gives you an idea of how you could cache DataSources, LocalHome's and
other "expensive to initialize" resources on your EJBs. I have ommitted
code that may re-initialize the DataSource should it become stale or
corrupted, etc.
===========================================================================
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".
