We have had good success with large Rete objects being accessed from an EJB
by using the Singleton pattern like this:
public class MySingletonRete
{
private static MySingletonRete onlyInstance = null;
private Rete m_Rete = null;
//private Constructor
private MySingletonRete()
{
m_Rete = new Rete();
m_Rete.executeCommand(...); //stuff to initialize the rules &
facts
...
}
//a static method for getting the only instance of the Singleton
public static MySingletonRete getInstance()
{
if (onlyInstance == null)
{
onlyInstance = new MySingletonRete();
}
return onlyInstance;
}
//an accessor for the Rete object
public Rete getRete()
{
return m_Rete;
}
}
in your EJB you would have code like this:
...
Rete myEJBRete = MySingletonRete.getInstance().getRete();
synchronized(myEJBRete)
{
...
myEJBRete.executeCommand(...);
...
}
...
This technique allows multiple EJB 'clients' to access a single Rete
instance that may be very large.
Hope this helps.
Burt
"James Patterson" <[EMAIL PROTECTED]>@sandia.gov on 03/04/2002
03:21:45 PM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: 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
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-----
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
