Re: J2EE Specification compliance

[Karthikeyan M]

You can use synchronization to sync up different threads for classes
inside the container. There was an earlier post in this forum that
talked about thread synchronization. It is only the EJB methods on which
you should not 'synchronize'. You can write helper/utility classes on
whose methods/classes you can synchronize. It is no better/worse than
using a Hashtable inside your EJBs.
-karthik.

Juan Pablo Lorandi wrote:

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".

===========================================================================
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".