Re: J2EE Specification compliance

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