Karthik, you're right, but that depends on the semantics of the system we're discussing.
Synchronization may or may not be a big issue here. Spawining N Threads all belonging to the same transaction could be a bigger issue. There could be other considerations as well. It's difficult to know for sure since there's little we know about the rules engine. If the engine spawns several worker threads that are supposed to run in a single transaction, then special, non-declarative transactional management would be in order. Bypassing the EJBs prohibitions such as direct file access, critical section handling, object and thread management, etc. is valid only in a subset of cases (I'd characterize those as "degenerate" cases). Multiple instances of the application running on one server, multiple JVM instances(even multiple app server instances or hosts), non-cluster wide file systems, cluster wide file systems, etc. change the scope of the impact. Not violating these "guidelines" assures to a great extent that the application will perform similary in very different deployment scenarios: I've had projects with Entity Beans persisted each on a different database, from a different vendor, without any code rewrites. Again, if Glenn discloses the nature of the engine and its(the engine's) need to, for instance, spawn worker threads we could sensibly recommend alternatives. One that comes to mind is to replace the worker threads for MDBs or something similar. Starting a worker thread would be replaced by posting a JMS message into a particular Queue. Synchronized parts of the engine could be replaced by a JVM-wide/application wide singleton or a SessionBean instance fa�ading (errr...) into the singleton. All in all, it boils down to the ability to make assumptions about the system they're implementing. There's always a tradeoff when porting into an app-server centric platform, such as J2EE. In very general broad terms, it's impossible to help Mr. Williams answer his question, which comes to this forum because it's been answered already by different people giving him opposite advice and sounding convincing (IMO because all of they are right, each from a certain point-of-view). Perhaps the solution could also be to fa�ade the rules engine behind a JCA adaptor; perhaps as a WebService. These also imply that some rewriting/refactoring/re-architecting would be in order. Maybe it's important to minimize the effort of porting, maybe it's important to migrate functionality while re-architecting so that the engine is quite sturdy. On the given input I honestly don't know, esp. since my crystal ball is at the service and my tarotist has left the country ;). My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > > > 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. =========================================================================== 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".
