EJB persistence versus Database persistence?

Discussion in 'Java' started by javaguy44, May 15, 2004.

  1. javaguy44

    javaguy44 Guest

    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
    javaguy44, May 15, 2004
    #1
    1. Advertising

  2. On 15 May 2004 14:20:49 -0700, javaguy44 <> 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 <>
    Craig Andrews, May 15, 2004
    #2
    1. Advertising

  3. javaguy44

    Michael Berg Guest

    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
    Michael Berg, May 16, 2004
    #3
  4. javaguy44

    Sudsy Guest

    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?
    Sudsy, May 16, 2004
    #4
  5. javaguy44

    Chris Smith Guest

    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
    Chris Smith, May 16, 2004
    #5
  6. javaguy44

    perry Guest

    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
    perry, May 16, 2004
    #6
  7. javaguy44

    javaguy44 Guest

    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.

    > (javaguy44) wrote in message >news:<>...
    > 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
    javaguy44, May 16, 2004
    #7
  8. javaguy44

    Sudsy Guest

    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...
    Sudsy, May 17, 2004
    #8
  9. javaguy44

    Michael Berg Guest

    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
    Michael Berg, May 17, 2004
    #9
  10. Chris Smith <> 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 (4638) /
    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
    Steven J Sobol, May 17, 2004
    #10
  11. javaguy44

    Michael Berg Guest

    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
    Michael Berg, May 18, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. javaguy44
    Replies:
    17
    Views:
    3,212
    Chris Smith
    May 18, 2004
  2. Replies:
    2
    Views:
    441
    Colin Lanning
    Mar 14, 2007
  3. Kenneth P. Turvey

    Java Persistence API and persistence.xml

    Kenneth P. Turvey, Mar 15, 2008, in forum: Java
    Replies:
    2
    Views:
    17,257
    Kenneth P. Turvey
    Mar 16, 2008
  4. Raymond Schanks
    Replies:
    0
    Views:
    643
    Raymond Schanks
    Aug 3, 2010
  5. Paul Butcher
    Replies:
    12
    Views:
    692
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page