Hi, Sorry for the lateness of this reply, my spam filter has decided to remove these emails.
Here's the specifics about our rules engine: The rules engine we are using does not create threads but manages the engine using synchronization. The rules engine is not serializable. We create a pool of rules engines, which are started in a separate thread and managed as a singleton. We have implemented management threads that we start to manage the users session in the rules engine. These threads unload the users data from the rules engine after a set amount of time. We do a bit of thread manipulation to make sure the user's session is executing correctly within the pooled rules engine. Some of these things can be implemented compliantly using EJB beans. Some cannot. But its the synchronization that is causing heart burn. I've read the thread here, read experts, and directly from the rules engine's author that we should be "ok" allowing the engine as long as it does not synchronize on the bean. But our EJB vendor has stated that its ok for now but not guaranteed to be ok in the future. So we've moved this out into another layer that participates with the EJB container and it works just fine but it's not how we envisioned the EJB architecture. So the issue is this: if the specification says don't use synchronization, the vendor says use it at your own risk, how can we even consider it? Thanks. glenn On Thu, 19 Feb 2004 16:05:22 -0000, Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote: >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". =========================================================================== 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".
