EJB persistence versus Database persistence?

[javaguy44]

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

 

[Craig Andrews]

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.

 

[Michael Berg]

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

 

[Sudsy]

Michael Berg wrote:

... 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...

...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?

 

[Chris Smith]

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

 

[perry]

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]

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.

 

[Sudsy]

Michael Berg wrote:

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




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...

 

[Michael Berg]

Hi,

</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

 

[Steven J Sobol]

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 (4638) / (e-mail address 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

 

[Michael Berg]

Hi,

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.

This all sounds so nice doesn't it. Unfortunately, in real life you need to
do a lot more than just that. For one, all application servers are
different, and so are the backend databases. You can code most of your
application in a fairly generic way, but when it comes down to it, you
almost always have to implement special code or setups that render your app
unportable anyway. I have not yet seen two EJB vendor implementations that
allowed you to actually do what J2EE promises.

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.

You can do this but you can also write a JDBC based application and have all
that as well as the ability to interact with non-java based systems in the
infrastructure. Any datastore that is based on java serialization is
confined to the Java universe, and while you and I may enjoy it here, it is
extremely unlikely that such a system is desirable to have in a mixed
technology environment.

Also, implementing a system evaluates to so much more than just writing code
from scratch and deploying it. You *have* to think about the context and the
lifetime of your application and the infrastructure in which it resides.
Your data will not remain in this schema forever - someone will ask that you
add or change entities, perhaps even radically, and it makes sense to
question the economic rationale for a J2EE based solution versus a JDBC
based solution, no matter how nice the J2EE ideal sounds.

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.

Let's just abolish once and for all this "toy" aura envelops MySQL shall we?
MySQL stopped being a toy database years ago, and is absolutely a worthy
contender in the enterprise field. It has always stood in the shadow of
PostgreSQL for a few, obscure technical reasons, but those days are long
gone. It scales and performs as well as any commercial product I have worked
with, and has most if not all of the same features. It also comes with
probably the most reliable JDBC driver of any relational database you can
think of.

MySQL is a conscious choice - not something to get because you can't afford
anything else. Doesn't google run their entire system on MySQL?

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

I'm not sure what you mean. The connecting layer between objects and the
physical database is the J2EE server, through deployment and naming
services.

/Michael