Hi;
Just wanted to add about singletons.
Its not about the JVM but about the classloader hirarchy of the specific app server.
If you truly expect one instance than you might want to bind it into JNDI but than you will have to synchronize access.
If you are using singletons for read only operations than write a singleton. Even though you will end up having 2-3 instances of it because of the classloaders, it is still a good option.
-----Original Message-----
From: Juan Pablo Lorandi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 18, 2004 10:20 PM
To: [EMAIL PROTECTED]
Subject: Re: J2EE Specification compliance
>
> The most challenging issue is conforming to the specification
> of the EJB container which states that thread manipulation is
> not allowed. We are using a rules engine to implement our
> business rules. The engine itself uses synchronization and by
> the letter of the J2EE specification this is not allowed. In
> conversations with our EJB container vendor, the author of
> the rules engine, and various members of the software
> community we've come to the conclusion that no one has a
> solid answer to this problem. Nothing prevents us from doing
> it, there are no compliance checks within the container. No
> yet anyway. Several people have suggested that the
> specifications are "really just guidelines" and its ok to use
> synchronization as long as we're not syncrhonizing beans.
> Others suggest (our Ejb vendor as well) that violating the
> specification could have immediate and long term affects.
Both are right :)
I'll try to explain the motivations for the spec to prohibit these, and
hopefully it'll be a bit more clear to you why you can bypass them, and
the price you'll be paying.
An EJB component, just like a CORBA component, or an MTS component,
benefits heavily of indirection. Indirection allows the app server to
provide for location transparency, thread management, declarative
transactions, declarative security, object pooling, and for EJBs,
automatic persistence.
Transactional activity, just as security credentials, are transversal to
your application. That's why most app server vendors, even MTS, like to
pair transactional activity with thread activity. This is usually
referred to as 'Thread affinity'. In practice, an app server
WorkerThread may look a bit like this:
public class WorkerThread extends Thread {
private TransactionalContext ctx;
public EntityContext getEntityContext() {
return ctx.toEntityContext();
}
//same for session beans.
}
A wrapper for each component is generated, and it usually looks like
this:
public class AppServerEJBWrapper_89098 extends MyEntityBean {
private void init() {
setEntityContext( //defined by the extended MyEntityBean
((WorkerThread)Thread.currentThread()
).getEntityContext()
);
}
}
This is the most viable design pattern used to implement indirection in
EJBs. This allows for the proper (declarative)transactional demarcation
of components and so forth. Think also that when the Wrapper instance is
out of the transaction, it should return to an object pool to be reused.
Tracking the usage down if they're used by non-container managed threads
could be troublesome, just like making a Singleton's constructor public
;)
Thread problems do not stop there. Assume two threads that run in the
same transaction are started. Then one finishes. The other's still busy.
Commit, Rollback, Panic? Transaction managers usually preemptively kill
transactions after a short timeout (I use 3 seconds). There's not much
point in launching Threads for this very short amount of time, after
all, they're not time slices.
>
> The compliant architecture we've come up with involves
> creating a Corba tier that can be used from within the EJB
> layer and will participate in transactions. We've found
> evidence that this type of architecture is being used by
> others as well. But it adds a layer of complexity that just
> doesn't feel quite right and makes for a very hard sell to management.
>
> We're also experiancing the same kind of design questions
> surrounding singleton's, thread pool management, and session time out.
Singleton's are only manageeable if there's only one JVM instance
running.
>
> So does anyone have any real world experiance where this type
> of issue has come up? If your violating the specfication how
> are you defining the guidelines to do that?
>
Essentially, without knowing why your rules engine creates Threads, it's
difficult to give advice, but how about this: the rules engine can be a
non-EJB component running outside the App Server. This allows you to
manage Threads freely.
The counter argument is (apart that extra-JVM communication is
expensive) that since it's not EJB based, then its maintenance costs
will rise.
There's more guidelines people around the forum can provide, but those
make assumptions, and it's difficult without knowing a bit more about
your rules engine.
HTH,
JP
===========================================================================
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".
______________________________________________________________________
This email message has been scanned by PineApp Mail-Secure and has been found clean.