Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   EJB - Why do we need java persistence on top of a database? (http://www.velocityreviews.com/forums/t133411-ejb-why-do-we-need-java-persistence-on-top-of-a-database.html)

javaguy44 05-12-2004 09:20 AM

EJB - Why do we need java persistence on top of a database?
 
Hi,

I'm new to EJB, and have done some tutorials etc. but haven't seen the
need for persistence yet.

As I understand it, making an object persistent means that the object
lives forever, even if there's a shut down of the app server. Is this
right?

Now my question is, what role does entity bean persistence play, that
a database cannot do? This is what I don't understand.

Thanks for helping a EJB newbie

Michael Borgwardt 05-12-2004 09:24 AM

Re: EJB - Why do we need java persistence on top of a database?
 
javaguy44 wrote:

> I'm new to EJB, and have done some tutorials etc. but haven't seen the
> need for persistence yet.
>
> As I understand it, making an object persistent means that the object
> lives forever, even if there's a shut down of the app server. Is this
> right?


Depends on how you define "live". The data is preserved and the object
can be recreated when needed.

> Now my question is, what role does entity bean persistence play, that
> a database cannot do? This is what I don't understand.


It's an additional abstraction layer that achieves a number of things:
- independance from specific database products
- transparent clustering
- declarative transaction definition


Fedor 05-12-2004 09:31 AM

Re: EJB - Why do we need java persistence on top of a database?
 
javaguy44 <javaguy44@yahoo.com> wrote:
> Hi,
>
> I'm new to EJB, and have done some tutorials etc. but haven't seen the
> need for persistence yet.
>
> As I understand it, making an object persistent means that the object
> lives forever, even if there's a shut down of the app server. Is this
> right?
>
> Now my question is, what role does entity bean persistence play, that
> a database cannot do? This is what I don't understand.
>

People always start talking about 'transactions'... Ask
them what a transaction actually is; that's quite funny :)

EJB is a hype consisting of some over-engineered frameworks.

Use plain sockets for communication and plain sql for persistancy.
That's much cleaner. This kind of stuff seems to be hard for
average programmers, so they invented all this EJB-crap and
made some wizards in WSAD......

Have you ever seen a real working EJB-application? Does amazon,
google, hotmail use them? I don't tink so... Is it necessary?
I don't think so....
When EJB is involved a project it 's all about adding more
hardware because performance is bad.



Fedor


Michael Borgwardt 05-12-2004 09:38 AM

Re: EJB - Why do we need java persistence on top of a database?
 
Fedor wrote:

> Use plain sockets for communication and plain sql for persistancy.
> That's much cleaner. This kind of stuff seems to be hard for
> average programmers, so they invented all this EJB-crap and
> made some wizards in WSAD......


Use plain assembler for programs, the "ed" editor to write the code.
That's much cleaner, but it seems to be hard for average programmers,
so they invented all this high-level language crap and made decadent
resource-wasting editors live vi.


> Have you ever seen a real working EJB-application? Does amazon,
> google, hotmail use them? I don't tink so... Is it necessary?
> I don't think so....


Nice demonstration of the "argument by baseless assertion" technique there...

Fedor 05-12-2004 10:38 AM

Re: EJB - Why do we need java persistence on top of a database?
 
Michael Borgwardt <brazil@brazils-animeland.de> wrote:
> javaguy44 wrote:
>
>> I'm new to EJB, and have done some tutorials etc. but haven't seen the
>> need for persistence yet.
>>

> It's an additional abstraction layer that achieves a number of things:
> - independance from specific database products


ANSI-SQL is database independent as well, and JDBC wraps
low-level interfaces to relational databases. If you ever have to
change SQL, because use want to use a new database (have you
ever seen a project where they switched to another DBMS?),
it's always less work than change your EJB-code to conform
a new EJB-standard used in a new version of the appserver, that
you have to use because the old one contains memory leaks,
and security bugs.

> - transparent clustering


Most of the time you have to buy more hardware because of the
overhead of EJB. Processors are fast enough to calculate a
game off chess 10 ply deep.
999 out of 1000 projects need clustering. If you write efficient
code, there is no need to cluster. And still, there is no need
to use EJB as long as sessions are serializable and your app-server
supports cloning, you can do load balancing.

> - declarative transaction definition
>

transaction? what's that?

Isn't a transaction an application level issue? Isn't that
'business logic'? And with JDBC you can just do rollback().
'declarative transactions' on the application level can
be implemented using;

if (enoughCredits)
execute();
else
rollBack();


Fedor.

Fedor 05-12-2004 10:49 AM

Re: EJB - Why do we need java persistence on top of a database?
 
Michael Borgwardt <brazil@brazils-animeland.de> wrote:
> Fedor wrote:
>
>> Use plain sockets for communication and plain sql for persistancy.
>> That's much cleaner. This kind of stuff seems to be hard for
>> average programmers, so they invented all this EJB-crap and
>> made some wizards in WSAD......

>
> Use plain assembler for programs, the "ed" editor to write the code.
> That's much cleaner, but it seems to be hard for average programmers,
> so they invented all this high-level language crap and made decadent
> resource-wasting editors live vi.
>

Assembly language not platform independent and therefor it could
be evil. EJB is even more evil, because it's EJB-spec-version-dependent.



Fedor.

Ryan Stewart 05-12-2004 12:01 PM

Re: EJB - Why do we need java persistence on top of a database?
 
"Fedor" <fedor@nospam.com> wrote in message
news:40a1feb0$0$97889$e4fe514c@dreader12.news.xs4a ll.nl...
> Michael Borgwardt <brazil@brazils-animeland.de> wrote:
> > javaguy44 wrote:
> >
> >> I'm new to EJB, and have done some tutorials etc. but haven't seen the
> >> need for persistence yet.
> >>

> > It's an additional abstraction layer that achieves a number of things:
> > - independance from specific database products

>
> ANSI-SQL is database independent as well, and JDBC wraps
> low-level interfaces to relational databases. If you ever have to
> change SQL, because use want to use a new database (have you
> ever seen a project where they switched to another DBMS?),

Yes, several in the past year.

> it's always less work than change your EJB-code to conform
> a new EJB-standard used in a new version of the appserver, that
> you have to use because the old one contains memory leaks,
> and security bugs.
>

I don't use EJB's, but using any of the persistence methods we use is *many*
times easier and less work than managing SQL statements.

> > - transparent clustering

>
> Most of the time you have to buy more hardware because of the
> overhead of EJB. Processors are fast enough to calculate a
> game off chess 10 ply deep.
> 999 out of 1000 projects need clustering. If you write efficient
> code, there is no need to cluster. And still, there is no need
> to use EJB as long as sessions are serializable and your app-server
> supports cloning, you can do load balancing.
>

So don't use EJB's if your application doesn't need them, but use some
persistence mechanism.

> > - declarative transaction definition
> >

> transaction? what's that?
>

A unit of interaction with the database which is all or none. It usually
consists of multiple updates (not in the SQL sense) to a database that must
be done as a unit to keep the database in a valid state. No changes are made
to the database until the entire transaction is complete. If any of the
updates fail, the transaction is rolled back so that none of them are
carried out. If all are successful, the transaction is committed, and the
changes are actually made.

> Isn't a transaction an application level issue? Isn't that
> 'business logic'?

Not necessarily.

> And with JDBC you can just do rollback().
> 'declarative transactions' on the application level can
> be implemented using;
>
> if (enoughCredits)
> execute();
> else
> rollBack();
>

What's your point? Any good persistence mechanism will allow this if you
really need it. I've never had reason to investigate EJBs myself, but
advising someone to use JDBC when you don't know his/her situation is bad.
JDBC is suitable only for the simplest applications and should still be used
in conjunction with some design pattern that will separate the database code
from the business logic. For anything besides very basic applications, look
into an object to relational architecture like TopLink, OJB, Hibernate, etc.



John C. Bollinger 05-12-2004 03:17 PM

Re: EJB - Why do we need java persistence on top of a database?
 
Fedor wrote:

> Isn't a transaction an application level issue? Isn't that
> 'business logic'? And with JDBC you can just do rollback().
> 'declarative transactions' on the application level can
> be implemented using;
>
> if (enoughCredits)
> execute();
> else
> rollBack();


A J2EE transaction may involve manipulation of many resources, including
one or many databases, business objects, and a few other things. J2EE
transactions provide a configurable level of isolation of seperate
concurrent transactions, and support for rolling back the whole thing.
The are much broader in scope than plain database transactions. J2EE
also provides for (but does not require) "container managed
transactions", which can significantly ease the burden of supporting
transactionality in a J2EE application.


John Bollinger
jobollin@indiana.edu


Roedy Green 05-12-2004 03:36 PM

Re: EJB - Why do we need java persistence on top of a database?
 
On 12 May 2004 02:20:57 -0700, javaguy44@yahoo.com (javaguy44) wrote
or quoted :

>Now my question is, what role does entity bean persistence play, that
>a database cannot do? This is what I don't understand.


See http://mindprod.com/jgloss/pod.html

The persistent object model allows for complex connections between
objects. Before you can use an SQL database for persistence, you have
to figure out how to store everything in tables.

PODs store complete objects. SQL stores fields.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Fedor 05-13-2004 06:54 AM

Re: EJB - Why do we need java persistence on top of a database?
 
Roedy Green <look-on@mindprod.com.invalid> wrote:
> On 12 May 2004 02:20:57 -0700, javaguy44@yahoo.com (javaguy44) wrote
> or quoted :
>
>>Now my question is, what role does entity bean persistence play, that
>>a database cannot do? This is what I don't understand.

>
> See http://mindprod.com/jgloss/pod.html
>
> The persistent object model allows for complex connections between
> objects. Before you can use an SQL database for persistence, you have
> to figure out how to store everything in tables.
>
> PODs store complete objects. SQL stores fields.
>

The objects living in java are the same as the objects living
in the database. A relational database is much more powerfull
and - in my opinion - usefull to exploit it's functionality.

A relational database is just a complex datastructure
which is able to manage large amounts of data. On top
of that you build a java-application in which you have
different objects, not copies of the database tabels!

For instance; in the database you have a table containing
customer data, an other table contains product information,
an you have tables containing orders and order lines.

Now, you can build a java application for planning
the routes of truck drivers and the way the truck should
be loaded. You're getting nowhere with object-persistance
stuff? You don't even want orderline, orders, customers
and products in your java-app. Your business logic on
the application level is implemented in java classes
like 'route', 'delivery' etc... These objects are constructed
by doing intelligent SQL-queries which cannot be generated
by frameworks.

I think this discussion is about developing an application
by starting with a relational database (which based on
mathematical rules) vs. starting with some object-model
(which is based on some recent software engineering 'theory').

Am I wrong here?




All times are GMT. The time now is 01:20 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.