Re: JESS: JESS & EJB

[James Patterson]

Title: RE: JESS: JESS & EJB

Technically I don't know the answer. My understanding is that a bean's life cycle is like the java GC - each implementation can handle it differently.  A good EJB should be service orientated - a request comes in, the bean is either instantiated or reused, and then the left for dead.  The container may or may not "destroy" it.  So, even though the bsave/bload option is there, it isn't very practical (I think) for my problem.  We have potentially, hundreds of rules and 10's of thousands of facts (most of which are not short and simple).  Most importantly, we are looking for a good response time on the "new fact -> rule fires" cycle.   Any comments?   James   ----- Original Message ----- From: rhalsey007 To: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 6:46 PM Subject: Re: JESS: JESS & EJB OK,   I went to the JESS mail archive, put EJB into the search box and VOILA !! - mucho references to many EJB/JESS questions/answers from the past. It looks like a stateful Session Bean can be used (along with bload/bsave) along with bean managed persistence.   One remaining question for any EJB jocks out there:   if I only have one bean (used expressly for JESS), but there are other beans in the application, why would the server single out my solitary JESS Session Bean to passivate over other session beans ? I was under the impression that if beans of a PARTICULAR type were needed, then the server would passivate some bean of that type to fulfill a request (using its LRU algorithm). Or am I wrong ?   Anyhoo, this weekend, I will begin construction of a stateful Session bean wrapper for JESS. Should be fun, and very informative.   Thanks,   Rich Halsey ----- Original Message ----- From: rhalsey007 To: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 5:41 PM Subject: Re: JESS: JESS & EJB Well, I was looking - but I was looking in the wrong places. The bload/bsave methods of the Rete class can save everything except the routers.   ----- Original Message ----- From: rhalsey007 To: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 5:16 PM Subject: Re: JESS: JESS & EJB To Bryan and James,   Yeah, I have been curious about having the (JESS) engine maintaining its state over a number of execution cycles.   One application that I have is only processing one new fact each time, but I have a number of facts (JavaBeans) that implement the "interface" into an application. These I want to remain in memory for matches against the newly asserted fact during a cycle. The RETE class in JESS implements the Serializable interface, so I guess I will have to come up with a "Bean Managed Persistence" approach to serialize the state of the engine if I put JESS inside a Stateful Bean. Something in my memory of this mailing list tells me that Earnest explained this once before. I am VERY new to J2EE, so I have to ask questions like I did today.   Thanks,   Rich Halsey ----- Original Message ----- From: Bryan Talbot To: '[EMAIL PROTECTED]' Sent: Thursday, February 28, 2002 4:38 PM Subject: RE: JESS: JESS & EJB -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My application uses a fairly static set of rules to process an XML document describing a business transaction.  Each document is processed individually and the rule engine is reset before each processing cycle.  So, I don't have a need for long term access to the same rule engine state that you seem to have. I'm not sure what my solution to solve that problem would be since I haven't looked at it much; I've been lucky and able to avoid using state full session beans. - -Bryan >-----Original Message----- >From: James Patterson [mailto:[EMAIL PROTECTED]] >Sent: Thursday, February 28, 2002 2:08 PM >To: [EMAIL PROTECTED] >Subject: Re: JESS: JESS & EJB > > >I'm curious what type of applications you guys are using the >engine for.  We are investigating the JMX route because of the >"normal" EJB rules.  For example, how do manage state?  The >engine use we are working toward is going to be a >run-all-the-time service.  Just because the engine maybe quite >for a given time, I can't have the container running around >trying to kill it off.  Now, I admit to being a bit >under-acquainted with J2EE as a whole, but how else does one >use/model the engine? I suppose if your rule base were small >enough and a persistent state was not required for long >periods of time, things might be more straight forward?  Comments? > >James > > -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.2 iQA/AwUBPH6xeUzuKKcxAa+OEQLbbQCgnEKW7mLeTB/Yr/LEh3XCr6h5Qg8AoJoT x+iMyz/V2Fh4AGQPqmz8tdF5 =gEx6 -----END PGP SIGNATURE-----