> > Here's the specifics about our rules engine: > The rules engine we are using does not create threads but > manages the engine using synchronization.
Why? Synchronization implies state shared amongst different units of execution. Which different units of execution may attempt to access some shared data? What is this shared data? > 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. Whoah. Hold on here. You're pooling the rules engines (wild guess: because initialization costs are high) AND managing threads? Why separate threads? Why not use the execution thread? > 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. This is done by most app servers. Usually it's called Heuristic Deadlock Detection. I take it that when the user's data is unloaded, that particular Thread/RulesEngine instance returns to the pool, right? > We do a bit of thread manipulation to > make sure the user's session is executing correctly within > the pooled rules engine. Why? Is there a danger of a worker thread/RE instance being called from 2 user sessions? If not, this is again Heuristic Deadlock Detection. > > Some of these things can be implemented compliantly using EJB > beans. Some cannot. Which 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. You're right, EJB architecture should be different. You shouldn't be managing threads in the first place. Ditto for object pooling, but this is more manageable. You're replicating a ton of code that is already in your app server. Many of the services the app server provides are delivered only if the postulate that the app server manages threads, object lifetime, etc. hold true. That's why it might not work in the future, or in some app servers, etc. Why are things this way? Essentially, the cost of implementing an app server that doesn't work under this postulate balloons out of proportion. This is why CORBA never got popular, and incidentally, why no 2 CORBA app servers from different vendors could ever integrate without a coder laying out the plumbing accordingly. > > 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? Don't. Just don't. Let the app server manage the threads. Use a factory class to pool RE instances. Release the instances back to the pool manually (like connection.close() ). Alternatively, you might want to consider using JCA (or even JDBC) to fa�ade the work you have now from the EJBs. Implement a JDBC "driver" (including DataSources) that interfases the EJBs from the Augmented Rules Engine (augmented: worker threads, synchronitazion, etc.) you have now. HTH, JP PS: I used to know a guy in Denver(close to you according to your site) by the name of Jay Armstrong who was quite familiar with EJBs and might be in a position to help you, if you show more of this to him(possibly under contract: I wouldn't know). Regrettably, I'm out of touch with him. I'll try to hunt him down if you want me to. =========================================================================== 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".
