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. ----- Original Message ----- From: "Johan Eltes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 19, 2002 7:05 AM Subject: Re: How to have generic business logic in session bean? > I'm not sure that I have understood your requirements. My interpretation of > your scenario is: > > 1) The method exceuteBusinessRule(String nameOfRule) is invoked by a client > on BusinessRuleService (SLSB) > 2) The SLSB calls findByPrimaryKey(nameOfRule) on BusinessRuleHome (EB) > 3) One of two alternatives: > a. The SLSB calls getRule() on the EB, which returns some kind of rule > representation. The SLSB then uses some rule-engine/parser utility to fire > the rule. > b. or...The SLSB calls the fireRule() method on the EB > > With SLSBs, you will never have 10000 instances in your app server. The App > server/EJB Container will only have one instance per concurrent thread > servicing a client request. I assume that one must expect that most "fired > rules" update the database. If you go for scenario 3a, you should be able to > declare the EB as none-transactional. That would let the container optimise > the usage of cached instances (no un-necessary load/store). With scenario > 3b, you would need a transactional EB ( to propagate the transation context, > which you need to get ev. resource managers used by the rule associated with > the container transaction). The container would then be forced to store/load > the entity bean instance for every request. > > /Johan > > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Joel Riedesel > Sent: den 19 januari 2002 01:06 > To: [EMAIL PROTECTED] > Subject: How to have generic business logic in session bean? > > Ok, new topic (I hope!). > > Now that I'm starting to understand how to use EJBs I'm having > some difficulty coming up with the proper architecture. > > > I've got a general business-logic representation. > One 'authors' their business logic (who cares how) and > then makes it available so that thousands of users > can 'use' the business logic. > > I want to map that to the app server, ejb world (why not, everyone > else seems to be doing it!). > > > The 'user session' data obviously equates to a bunch of entity > beans. > > But the business logic ought to be a session bean. Except > that it is a generic session bean that somehow needs its > 'logic' loaded in in order to 'enact' the what the > authored logic does. (Think of it as a scripting language > where the evaluator is in the session bean, but the stuff > that is being evaluated is loaded in dynamically.) > > > Now, if I have 10,000 users hitting the app server, that's 10,000 > session bean instances. They are all using the same 'business logic'. > (But these 10,000 uses all have their own data, so the entity beans > all do the right thing with scalability, etc.) > > How the heck can the loading of the session bean be done efficiently? > (That's my question.) > > Because I want to think of this as application-logic, business-logic, > there is only one application (so to speak), but many users. > (Modelling the application/business logic as an entity bean means that > it is read 10,000 times even though it is not changing.) > > Or is there a better way to think about this? > > Joel > > =========================================================================== > 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". > =========================================================================== 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".
