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. 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.
What do you loose when not using Session
Beans
1. 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".
===========================================================================
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".
