If cache synchronization is not an issue (restart the app servers is fine,
in order to activate a new set of "interpreted logic" or whatever data you
are caching) I would go for the simple solution ( estimate the load and by
the memory I need).

/Johan

-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Joel Riedesel
Sent: den 19 januari 2002 17:03
To: [EMAIL PROTECTED]
Subject: Re: How to have generic business logic in session bean?

Ok, I suspect that we are talking about the same things, but perhaps
my problem isn't sufficiently clear.

I think we're just quibbling about the exact number of concurrent
instances of an EB that may exist.  I don't really care if it's
1000, 10,000, or even, only 100.

My problem is that if that EB is sufficiently large, say about 1MB,
then even having only 100 EBs for it is quite large.  I have to
use some sort of version of the Seppuku pattern it seems to make that
work well (read-mostly).

How does one do that portably?
I'm not targeting any specific application server.


Am I just being dense?  Is there only one instance of the EB or
would there be more than one instance if there are multiple session beans
making a call on it concurrently.  It's easy to realize that if
there were only one instance of the EB that the calls would have
to be synchronized - so that's not good, there must be
multiple instances of the EB.  That's my issue.  I don't want
to duplicate that EB data more than once (since it's essentially
read-only).

And how to do this portably?

Thanks... I'm relatively new to this EJB stuff and am still
filling in the details of my 'gestalt' of what's going on.

Joel



----- Original Message -----
From: "Johan Eltes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 19, 2002 8:41 AM
Subject: Re: How to have generic business logic in session bean?


> See comments inline...
>
> -----Original Message-----
> From: Joel Riedesel [mailto:[EMAIL PROTECTED]]
> Sent: den 19 januari 2002 15:29
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Re: How to have generic business logic in session bean?
>
> I don't think you did completely understand what I was asking
> for (not that I was entirely clear).  But you do raise further
> points.
>
> Suppose I have a SLSB: If Balance too High then Set Flag (or some such).
>
> If there are 10,000 concurrent sessions, then there'd be 10,000 of
> these, right?
> No. There would only be one instance per concurrently executing request. I
> don't think there are many web app on earth that need to service 10000
> concurrent REQUEST, but maybe 10000 concurrently existing (created and not
> yet timed out) sessions (http sessions or SFSBs).
>
>
> Now, the entities are things like account balance EB, etc.
> So, the session bean looks up the entity bean, gets the values, decides
> what to do, etc.  Pretty straightforward.
>
>
> But, I want my SLSB to be generic.  I want to somehow 'load' the
> logic that it uses to process the request.  Is that logic that it
> 'loads' from an EB or from somewhere else?  If from an EB, then
> with 10,000 concurrent sessions, doesn't that require 10,000 instances
> of the EB and thus 10,000 loads from the database into those EBs?
> What am I missing in my interpretation? I suggested that the business
logic
> (called "BusinessRule") is loaded by an EB. The number of concurrent SLSB
> instances would (as you state) cascade to the number of EB instances, if
the
> app server supports multiple instances of an EB class for the same primary
> key value. Not all do. For app servers that don't, you would get serious
> contention problems, since every request would be serialized by that
single
> EB (if many concurrent requests ask for the same business rule). Johns
> suggestion, I assume, is based on the assumption that the developer would
> make a more efficient key/object map implementation than using the
> containers key/entity instance map. Why would it be sensible to assume
this?
> Maybe I'm trying to solve another problem than you guys :)
>
>
> (Of course, once there is a 'good' number of EBs cached in the
> server, and if they are non-transactional - how does one make
> an EB non-transactional? - then no more loads need to be done,
> essentially.)
> This can only be achieved in a portable way using EJB 1.1. EJB 2.0 does
> allow you to use transaction demarcation "NotSupported" for entity beans.
As
> John pointed out - the vendors often provide none-portable solutions.
>
>
> Even still, suppose this 'logic' EB is large - say, 1 Megabyte in
> size.  10,000 of them would be kinda, uh, large.  It'd sure be
> nice for that EB to be sharable among all the 10,000 concurrent
> sessions via the generic SLSB.  Is there some way to make that happen?
>
>
> Do you mean http sessions or instances of SLBSs? The word "Session" used
in
> "Steless Session bean" is somewhat contradictory. A steles sessionbean
does
> not have any relationship to a http-session or the calling users session.
It
> is associated with the caller only for the moment it is executing its
> method.
>
>

===========================================================================
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".

Reply via email to