Re: Messaging Bean

[Sanjeev Verma]

Ok, doubt - please see inline... Peter Verkest wrote: ïWhen using normal java classes called from your MDB you do not loose scalability (pooling) nor transactions: your MDB already provides you with a pool of MDB instances. ********************************************* in my understanding, if we have simple classes instead of Sessions Beans, we will have a situation where: MDB pool instance A needs instance of class X MDB pool instance B needs instance of class X MDB pool instance C needs instance of class X . . . MDB pool instance n needs instance of class X So to serve n instances of MDB, the system will instantiate n instances of Class X. Is that correct? If yes, then session beans do take care of the scalability, right? ******************************************** Using session beans here for pooling purposes won't make the system more scalable. Concerning the transactions, I think it's possible to specify your MDBs to use 'Required' (or 'NotSupported') as transaction attribute, so the transactions are there as well. ******************************************** I kind of agree on this, but if we do this, we are still limiting (only two options) out transcation related options. We will not be able to do fine graining if required. What i mean to say is, lets say MDB A call SLSB methods X, Y, Z. The MDB method could have a attribute "Required" defined on it, and the SLSB methods could have there own transcation attributes defined in turn. Now lets say my application logic wants that "I don't care if the DB operation by method X fails, it is OK, i don't want to rollback on that", then I can do it with "NotSupported" attribute on X, and appropriate attributes on Y and Z. I can definately noy do this if I use simple classes. Or am I missing something here. ****************************************** What do you loose when not using Session Beans1. Distribution / load balancing: with session beans it's easy to call business logic residing on other servers. On the other hand, you could deploy this MDB on all servers in your cluster and WebLogic will do the load balancing on the MDB level for you.2. You loose the possibility to use simple, synchronous access to your business logic: calling session beans from JUnit, a web tier or a Swing client is easy.Depending on the use of your billions of records, you might consider using CMP entity beans or not: if e.g. 80% of the use cases READ in the same set of thousands of records, entity beans could be very interesting. ---Peter Verkest ----- Original Message ----- From:Sanjeev Verma To: [EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 7:24 PM Subject: Re: Messaging Bean  Normally speaking, I try to link EJBs with two advantages: 1. Scability - pooling is a big asset, and this is managed by the container. 2. Transcation - since you are talking about "Billions of rows of data", this would be important to you, and it makes more sense to exploit the declarative transaction management that comes along with EJBs. I would not know much about the cluster setup/management in weblogic, but reading the scenario you have described, it should not be a problem. I woul suggest you read the weblogic docs for details on this. So coming back to "what do we loose". Well, we loose both the above services, besides others that i have not even mentioned. So if you want to do pooling, you will need to implement your own pooling logic, which will be like re inventing the wheel. And even more tricky will be transaction management. And since you will be using the container for deploying MDBs anyways, it makes sense to use Stateless Session beans since the infrastructure is already there. Another important thing you may want to consider at the design stage is creating caches, such that every time data is needed, its not a trip to the DB - this is a costly operation and if avoided thru' caching, can result in major improvements. Invest time in learning some time tested patterns used in J2EE development in the caching area. Hope this helps. Best Regards Sanjeev Sachin Tandon wrote: Hi  We are using Messaging Beans on our project. The message bean in turn will be calling different java classes for performing some actions. The java classes will be having business logic and will access the DB. We will process billions of records. I wanted to decide on using EJBs against normal java classes in this scenario. 1)Billions of rows of data to be processed 2)Lots of calculation involved in processing data 3)Weblogic clustering Ã?? need to load balance requests received by MDB across instances. Any thoughts? What do we loose when we use normal java classes in this scenario as against using session beans Thanks =========================================================================== 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". --  Best Regards Sanjeev Verma Sun ONE App Server Migration Consultant Web Services, Tools and Migration Tools Market Development Engineering   =========================================================================== 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". --  Best Regards Sanjeev Verma Sun ONE App Server Migration Consultant Web Services, Tools and Migration Tools Market Development Engineering   =========================================================================== 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".