Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > EJB persistence versus Database persistence?

Reply
Thread Tools

EJB persistence versus Database persistence?

 
 
javaguy44
Guest
Posts: n/a
 
      05-15-2004
Hi,

I'm new to EJB, and have done some tutorials etc on developing EJB,
but I'm missing something fundamental.

Why do we need to have a java object persisted, especially one that is
holding values from a database? Can someone please explain this, as I
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.

I have looked on the internet, and read various articles, but I
still don't get why I would need to build persistent java objects on
top of a database.

An example would be even better. Thanks.

Thanks for helping a EJB newbie
 
Reply With Quote
 
 
 
 
Craig Andrews
Guest
Posts: n/a
 
      05-15-2004
On 15 May 2004 14:20:49 -0700, javaguy44 <(E-Mail Removed)> wrote:
> Now my question is, what role does entity bean persistence play,
> that a database cannot do? This is what I don't understand.
>
> I have looked on the internet, and read various articles, but I
> still don't get why I would need to build persistent java objects on
> top of a database.


EJB is just a framework for providing a common way to 'do' persistence.
The actual mechanism for persistence could be serialisation to a file
system, or it could be in a database. One way or another, entity beans end
up living forever and session beans end up dead. The precise details are
implementation specific, as long as the bean is Serializable.

--
Craig Andrews <(E-Mail Removed)>
 
Reply With Quote
 
 
 
 
Michael Berg
Guest
Posts: n/a
 
      05-16-2004
Hi,

> I have looked on the internet, and read various articles, but I
> still don't get why I would need to build persistent java objects on
> top of a database.


Good question. In fact, better than you think. Oppinions are divided.

It makes some sense to try to implement EJB session beans, but persisting
entity beans really adds very few benefits. In fact it has a number of
serious downsides. Not only is performance degraded because of bean
serialization and deserialization (type mappings), but schema evolution is
considerably more complicated. Remove a field from one of your beans and see
how well you sleep the night before going into production.

You should also consider how your application will interact with the rest of
the infrastructure. If at any time you find yourself having to connect an
external system directly to your EJB datastore, then I advise against using
EJB.

The best things you get from EJB are standards for the sake of standards
(selling points), and some technical benefits from not having to worry (too
much) about which database is being used or how to access it. But does that
justify the tremendously more costly infrastructure and overall complexity
of such a solution, as compared to a JDBC based solution? Any java developer
can put together a MySQL application that performs with perfectly acceptable
speed in most cases.

I guess it's up to you to discover which you are most comfortable with, and
what works best in any given situation.

/Michael
www.bergconsult.com
www.hyperpal.com


 
Reply With Quote
 
Sudsy
Guest
Posts: n/a
 
      05-16-2004
Michael Berg wrote:
<snip>
> ... Remove a field from one of your beans and see
> how well you sleep the night before going into production.

</snip>

But is that a realistic scenario? I don't recall a single situation
in my professional experience where a field was dropped from a table.
Added, certainly...

<snip>
> ...But does that
> justify the tremendously more costly infrastructure and overall complexity
> of such a solution, as compared to a JDBC based solution?...

</snip>

While I don't have the time to test right now, I'd be interested in
the actually performance hit of using entity EJBs (CMP) vs stateless
session beans using JDBC. With component reuse, my instincts suggest
that the deltas might be very revealing. They might even debunk some
commonly held beliefs...
Anyone looking for a thesis topic?

 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      05-16-2004
perry wrote:
> if you going to be collecting any amount of variable data
> then an investment in MySQL is typically the route to go. unless you got
> the bucks for something bigger.


For the most part, in any application where EJBs are required you
probably want reliable transactional and referential integrity, though.
Watch out: you can get that from the latest versions of MySQL, *if* you
do everything right and use their non-standard SQL extensions when
creating your database schema, but if you do something wrong, the
database will pretend to be giving you transactions and referential
integrity checking, but will silently ignore these promises when it
comes down to the wire.

Several other databases (such as PostgreSQL) are free and provide
reliable transactions and data integrity without non-standard extensions
to SQL and with reasonable error messages if you get something wrong.
MySQL claims to be free only when you're deploying a non-GPLed
application... you decide if you want to actually exercise your GPL
rights and get sued, or bow to them and buy a license (which is at least
much cheaper than Oracle, for example).

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
perry
Guest
Posts: n/a
 
      05-16-2004
going back to the age old relational database vs. object database
arguments... J2EE steps above all that by trying to give you the option
and responsibility to store and retrieve your objects whereever and
however you want. the layer you have to write is the connection between
your objects (beans) and the actual database subsystem that you choose.
you do not actually build a whole database system. now depending on the
volumn of objects you'll need, will determine what kind of backend
database to employ. for a really small object database simply use object
streaming. if you going to be collecting any amount of variable data
then an investment in MySQL is typically the route to go. unless you got
the bucks for something bigger.

but do you understand what i mean by simply writing the connecting layer
between your objects and the actual database ?

- perry

javaguy44 wrote:
> Hi,
>
> I'm new to EJB, and have done some tutorials etc on developing EJB,
> but I'm missing something fundamental.
>
> Why do we need to have a java object persisted, especially one that is
> holding values from a database? Can someone please explain this, as I
> 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.
>
> I have looked on the internet, and read various articles, but I
> still don't get why I would need to build persistent java objects on
> top of a database.
>
> An example would be even better. Thanks.
>
> Thanks for helping a EJB newbie


 
Reply With Quote
 
javaguy44
Guest
Posts: n/a
 
      05-16-2004
Hey everyone,

Thanks for your input.

I think I've got it....and so here is my quick
interpretation...correct me if I'm wrong.

As I understand it, if I mark an EJB / field as persistent in my code,
I am merely telling the EJB container that this object lives forever,
living in a database or some other form. At this point, according to
the spec, I'm supposed to relax a bit, as the EJB container is
supposed to take care of the low level API's(concurrency, threading,
etc.) so that I can concentrate on the business logic.

I'm new to EJBs...I've implemented straight MVC(Struts, Tomcat)
solutions with JDBC.

Thanks.

>(E-Mail Removed) (javaguy44) wrote in message >news:<(E-Mail Removed) .com>...
> Hi,
>
> I'm new to EJB, and have done some tutorials etc on developing EJB,
> but I'm missing something fundamental.
>
> Why do we need to have a java object persisted, especially one that is
> holding values from a database? Can someone please explain this, as I
> 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.
>
> I have looked on the internet, and read various articles, but I
> still don't get why I would need to build persistent java objects on
> top of a database.
>
> An example would be even better. Thanks.
>
> Thanks for helping a EJB newbie

 
Reply With Quote
 
Sudsy
Guest
Posts: n/a
 
      05-17-2004
Michael Berg wrote:
<snip>
> I have not tried this but I find it hard to believe that traversing a
> resultset is less efficient than going through JNDI and type mapping
> protocols on an application server. Yes, perhaps the server can pull a few
> tricks using caching schemes, but I can cache my resultset as well
>
>
>>that the deltas might be very revealing. They might even debunk some
>>commonly held beliefs...

>
>
> Regardless of the outcome I would certainly like to see such a test. My
> guess is the results will vary greatly, depending on the application server.


Drop me a line off-list and we'll set up a test. I've got Oracle 8 and
the DB/2 "Stinger" preview available as well as WebSphere and JBoss. I'd
like your code for the stateless session EJBs using JDBC and I'll
contribute the entity (CMP) code. It'll take a few days to normalize the
test environment, but the results could be interesting. Now if we
could get JDJ to pony-up some funding then we could make an article out
of this...

 
Reply With Quote
 
Michael Berg
Guest
Posts: n/a
 
      05-17-2004
Hi,

> > ... Remove a field from one of your beans and see
> > how well you sleep the night before going into production.

> </snip>
>
> But is that a realistic scenario? I don't recall a single situation
> in my professional experience where a field was dropped from a table.
> Added, certainly...


I agree that adding fields are the most common type of schema evolution, but
column deletion and type changes are not that unusual. Adding fields can
also be problematic (well, certainly something to pay attention to) because
of bean serialization and type mapping issues in existing data.

And even if you feel you can live with not being able to change field types
or drop fields, I would have to question the logic in going from a system
that gives you this for free at comparatively low complexity, to a system
that denies you this and at the same time introduces additional complexity.
It takes some very convincing arguments to justify this.

> While I don't have the time to test right now, I'd be interested in
> the actually performance hit of using entity EJBs (CMP) vs stateless
> session beans using JDBC.


I have not tried this but I find it hard to believe that traversing a
resultset is less efficient than going through JNDI and type mapping
protocols on an application server. Yes, perhaps the server can pull a few
tricks using caching schemes, but I can cache my resultset as well

> that the deltas might be very revealing. They might even debunk some
> commonly held beliefs...


Regardless of the outcome I would certainly like to see such a test. My
guess is the results will vary greatly, depending on the application server.

/Michael


 
Reply With Quote
 
Steven J Sobol
Guest
Posts: n/a
 
      05-17-2004
Chris Smith <(E-Mail Removed)> wrote:
> perry wrote:
>> if you going to be collecting any amount of variable data
>> then an investment in MySQL is typically the route to go. unless you got
>> the bucks for something bigger.

>
> For the most part, in any application where EJBs are required you
> probably want reliable transactional and referential integrity, though.
> Watch out: you can get that from the latest versions of MySQL, *if* you
> do everything right and use their non-standard SQL extensions when
> creating your database schema, but if you do something wrong, the
> database will pretend to be giving you transactions and referential
> integrity checking, but will silently ignore these promises when it
> comes down to the wire.


Yes, I have determined that after installing MySQL 4. I don't like it.
There are two table types that support transactions and you should get an
error message when attempting to use transactions with any other table type.

That having been said, transactions do work with the InnoDB or BDB table
types.

--
JustThe.net Internet & New Media Services, Apple Valley, CA PGP: 0xE3AE35ED
Steven J. Sobol, Geek In Charge / 888.480.4NET (463 / http://www.velocityreviews.com/forums/(E-Mail Removed)
Domain Names, $9.95/yr, 24x7 service: http://DomainNames.JustThe.net/
"someone once called me a sofa, but i didn't feel compelled to rush out and buy
slip covers." -adam brower * Hiroshima '45, Chernobyl '86, Windows 98/2000/2003
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Possible to generate "ejb-jar.xml" from EJB class (source)? "ejb-jar.xml" appserver independent? Raymond Schanks Java 0 08-03-2010 08:21 AM
Re: Mozilla versus IE versus Opera versus Safari Peter Potamus the Purple Hippo Firefox 0 05-08-2008 12:56 PM
Java Persistence API and persistence.xml Kenneth P. Turvey Java 2 03-16-2008 12:08 AM
equal? versus eql? versus == versus === verus <=> Paul Butcher Ruby 12 11-28-2007 06:06 AM
EJB - Why do we need java persistence on top of a database? javaguy44 Java 17 05-17-2004 11:01 PM



Advertisments