Hi Joe,
The functionality provided to you by the EJB container is time that you
cannot make up by a generator. Just think about connection pooling,
transaction management, etc. When you're using EJBs all these are ready for
you to use, without having to write a single line of code. You can't beat
that with straight JDBC coding.
Regards,
Dimitar
-----Original Message-----
From: Joe Schell [mailto:jschell@;PLBB.NET]
Sent: Friday, October 11, 2002 2:28 PM
To: [EMAIL PROTECTED]
Subject: Re: the truth about entity beans
Juan Pablo Lorandi wrote:
>
> My point is: EBs do not provide per se any boost in performance that you
> couldn't code yourself using JDBC. Benefits of using EBs are connected
> with faster coding, no need to know about RDBMS, RBDMS independence, and
> less maintenance costs.
>
I question the assertion that it takes less time to code.
I always code JDBC and EJBs using code generation. Given that there is
at least one more layer in EJBs that means one more layer to be
generated. And thus for the techniques I use (rolling my own generation
tools) that means that EJBs always take longer.
And I can't see that someone manually generating code is going to take
less time. There are still more layers.
So I can only guess that you are using a tool that generates
everything. But if it generates everything for EJBs then surely it can
generate everything for JDBC? Which means the coding speed would be the
same.
Perhaps you are referring really not to EJBs themselves but the wrapper
functionality that the EJB server provides and that one might have to
then code when using just JDBC?
> Marginal performance boosts are available. I use Orion
> extensively(altough I've worked with other app servers). Apart from the
> extra fast web server(quite a lot faster than Tomcat), Orion implements
> caching techniques that minimize database hits that, while could be
> coded with raw JDBC, are quite difficult to implement. Also, as the spec
> and the server itself mature, optimizations refine(at no cost to me),
> bringing even more performance boosts.
>
Caching obviously has an advantage.
I have worked on a number of projects over the years with persisted
data. I have worked in telcom, banking and the health industries.
And the data (both with EJBs and long before they existed) that I have
seen has the following characteristics.
--A. The data set was so small and the requirements of the system so low
that EJBs would be overkill and even caching of any of the data was not
needed.
--B. There was massive amounts of data. Most of the data was never
reused. At least not to extent that it could be cached. With 100s of
millions of entries used only once a day there wouldn't be a need.
However some data was cachable.
Presumably that last part (the cachable data) is where some advantage is
gained. But in my experience that data has the following properties.
1. The data set is extremely small, perhaps only a few hundred items.
2. Both by instance count and by object count the data that is reusable
forms a very small subset of the rest of the objects.
Now certainly because of the first property any caching technology, no
matter how fast, is going to be fast enough. Especially if it gets hit
only with another piece of data that must be queried from the database.
The second property leads to the following supposition. The system is
spending most of its time caching data that will never be used again.
This is due both because of the number of instances and the count of
objects. Now obviously this second item can be dealt with by tuning and
simply not using EJBs for everything. But that seems like an odd
position to take when you are spending a significant amount of money on
a EJB server and yet are not using it for more than 90% (or 99%) of the
data.
Now I can certainly imagine data sets that did not follow the above.
But I find it hard to believe that most data sets don't look like the
above.
===========================================================================
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".
