Phil,
Some thoughts below, and some blatent self serving GemStone/J boosting.
Regards,
-Chris.
----------------------------------------------------------------------
Chris Raber, Director Professional Services, GemStone Systems Inc.
100 West Big Beaver, Suite 200, Troy, MI 48084
phone: (248)-680-6691, fax: (248)-680-6689,
email: [EMAIL PROTECTED]
web: http://www.gemstone.com/
----------------------------------------------------------------------
> -----Original Message-----
> I am designing a system that includes a neural network engine. An
> equivalent
> system is currently working on the MS platform, but is very unscalable.
>
> I want to be able to pool neural network beans, as requests for searches
> are
> fairly rare, but come from many many clients.
>
Is it the bean's you wish to pool or the underlying NN's? Are these
underlying NN's Java objects?
> However, there are many different instances of NN, all represented by the
> same class.
>
> Specifically, there is a NN for each category that the user can perform a
> search against. These categories are completely unrelated to each other.
>
Does the user need to talk to each different NN directly? Or could a session
bean wrap the access to the underlying NN by category? The idea would be to
have a facade interface to the underlying NN's, and to pass in the category
and other arguments at invocation time.
> The stae of each net is stored in a file. For a large net, it can take in
> the order of 2 seconds to read the file and build the net, using highly
> optimised C++, so I can't load the net on each request (search turnaround
> must be sub one second).
>
It sounds like the "state of each net" is a static graph of meta
information. Is this accurate? Where is the run-time state of a net? Can it
be separated from the static state (motivation below).
> I have determined (so far) the following possibilities:
>
> 1. Maintain a pool of session beans, each of which loads all nets.
> However,
> each session bean could become quite large. Is there any way for me to
> determine how large? I know how to work out how many nodes and arcs a net
> will have from a given data set, and how many ints, floats ...etc that
> will
> be created, but I don't think that just adding up the storage requirements
> of the native types at the leaves of the object tree will tell me how much
> storage will actually be need by an instance of a bean running in a
> container.
>
Sounds like a bad idea. Why have all that duplicated data instantiated. You
need a shared caching mechanism here.
<vendor>
It sounds like a shared caching capability would be of tremendous value. If
you can pre-load the NN's into a shared object cache (e.g. GemStone/J's
PCA), then each NN type need only be loaded into the cache once, and then
individual invocations can map to the need NN at invocation time. Are the
nets themselves are stateless?
</vendor>
> 2. Represent each net as an entity bean and then have session beans
> that do
> findByPrimaryKey to get a handle on the correct net during the session.
> What
> happens if two sessions both try to call the same method on it at the same
> time? And how do I cope with the fact that the entity does not actually
> represent a db entity?
>
It doesn't matter where the state of an entity bean comes from (it doesn't
have to be rdbms based). Are the nets themselves stateless? If so, then
multiple clients invocing on them at the same time is a non-issue. Can the
meta structure of your nets be seperated from any dynamic run-time state?
> 3. A third aletrnative is to have session beans that use an LRU
> algorithm to
> maintain a truncated list of nets. This would mean that the user would
> occaisionally experience slight delay as the appropriate net is loaded.
> (Load time could be reduced to the order of .5 seconds in this scenario,
> by
> using a selective load algorithm).
>
<vendor>
If you load the nets into GemStone/J's PCA then the server's built in LRU
will do this automatically. You configure the allocated amount of shared
memory and disk base to GemStone/J, so you can control how much of the
objects state is really in memory vs. paged out to disk.
</vendor>
> It seems like in point 3 I am trying to do something that EJB itself
> should
> be doing, and I wonder if I'm missing something.
>
<vendor>
Depends on what sort of server beasty you use now doesn't it!
</vendor>
> If anyone can comment on this, I'd be very grateful.
>
> Phil Lewis
> Technical Architect
> Neural Response Ltd
> [EMAIL PROTECTED]
>
> ==========================================================================
> =
> 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".
