ï
About the pooling:
1. If you're saying session bean, I suppose you
mean stateless session bean, so X could be a singleton.
2. The MDB pool we're talking about will limit the
number of concurrent MDB instances, so n will be small. The only performance hit
to take here is pure object creation / garbage collection for every message. Is
that such a problem? If it is, I might prefer a simple Object pool above a
heavier Session Bean.
3. To me, session beans have a remote interface and
use pass by value. This serialization and deserialization will do more harm to
performance than the object creation / garbage collection from 3.
I agree that you loose fine-graining on
transcations, but from your reply I had the impression that you meant no
transactions at all were possible.
---
Peter Verkest
----- Original Message -----
Sent: Wednesday, December 17, 2003 7:38
PM
Subject: Re: Messaging Bean
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 -----
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".
===========================================================================
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".
|
