> Phil,
>
> Some thoughts below, and some blatent self serving GemStone/J boosting.
>
I don't mind vendor specific stuff. You're trying to help...
However, we can't tie ourselves down to a single provider, as we sell the
software, it's not for in-house.
> > 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?
It's really the underlying NN's. Perhaps we've already gonme to deep. What I
*actually* want to do is ensure that the NN's can service several thousand
requests an hour average, with a peak of ten time that. (And maybe even
more. If Yahoo! get interested in our technology (and they need it ;-), then
I want to be able to handle that volume.)
> > 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 user passes an ID with the query that specifies which NN to use.
> > 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 keep talking the our net guy, and he insists that there is no runtime
state as such. I'm suspicious, but that's what he says. Apparently there are
no module level or static variables.
>
> > 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>
Does sound good, but if only you do it, or you do it in a vendor specific
way, then this is a black mark for you...
> > 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?
Meta structure is staic at query time, and there is no dynamic state (see
above). So multiple clients can invoke an entity bean simultaneously?
(aasuming no transactions).
> > 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>
Again, sounds excellent, but I can't tie my code to one vendor (no matter
how helpful :-)
Of course, it might be an option to negotiate a distribution agreement, but
if this is somewhere you could go, I'd have to talk to my business guys
first.
Thanks for a couple of suggestions and pointers.
===========================================================================
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".
