Discussions

News: Tech Talk: Seth White of BEA talks about EJB 3

Bookmark and Share Get thread feed

  1. Tech Talk: Seth White of BEA talks about EJB 3 (13 messages)

    • Posted by: Dion Almaer
    • Posted on: January 18 2005 10:56 EST
    Seth White, lead engineer on the WebLogic EJB team provides a comprehensive view of EJB 3 and what it will mean for developers. Seth answers questions such as why do we still need deployment descriptors, how disconnected data access will work in an EJB environment, and what the EJB expert group is working on now.

    You can view it here:
    http://dev2dev.bea.com/trainingevents/dev2devlive/sethwhite.jsp

    The talk was filmed in Nov, 2004, for BEA's Dev2dev portal.
    Reply to this

    Threaded Messages (13)

  2. Tech Talk: Seth White of BEA talks about EJB 3[ Go to top ]

    When publishing these interviews, please note on what date the interview was conducted.
    Reply to this Reply to original

  3. layout[ Go to top ]

    I'd like to suggest a change of layout for these video interviews. I think it would look better if you had the links below the video screen and the transcript on the side, to facilitate reading. I'm sure I'm not the only one who prefers reading the transcripts, and the current layout makes it a frustrating experience.

    Joe
    Reply to this Reply to original

  4. container impacting DB structure?[ Go to top ]

    The version attribute is not required to be exposed in the object model, it is required to be present in the database so that it can be used by the container

    I was a bit taken aback by this. Am I the only one amazed to hear that entity beans will require an extra field in the database, for each and every table?

    This apparently precludes the use of EJB 3.0 entity beans for existing (and unmodifiable) DB schema.
    Reply to this Reply to original

  5. container impacting DB structure?[ Go to top ]

    The version attribute is not required to be exposed in the object model, it is required to be present in the database so that it can be used by the container
    I was a bit taken aback by this. Am I the only one amazed to hear that entity beans will require an extra field in the database, for each and every table? This apparently precludes the use of EJB 3.0 entity beans for existing (and unmodifiable) DB schema.

    This is untrue.
    Reply to this Reply to original

  6. container impacting DB structure?[ Go to top ]

    Would you mind elaborating if you have the time? Otherwise a pointer to more info would be just and useful.
    Thanks Bill.

    Regards
    Mike
    Reply to this Reply to original

  7. container impacting DB structure?[ Go to top ]

    An extra column is needed *if and only if* you use the optimistic locking strategy through the @Version attribute.
    It is absolutly not required to be on every entity bean table
    Reply to this Reply to original

  8. container impacting DB structure?[ Go to top ]

    Well indeed container impacting DB structure. For example if a DB itself implements locking using multiversion concurrency control no one oblige you to create an extra filed in the table! Why not to use kinda helper tables for that.
    Reply to this Reply to original

  9. container impacting DB structure?[ Go to top ]

    Well indeed container impacting DB structure. For example if a DB itself implements locking using multiversion concurrency control no one oblige you to create an extra filed in the table! Why not to use kinda helper tables for that.

    This is an implementation issue. We should not believe that the spec will define how tables, columns, contraints and indexes will be. There will probably have only a bunch of interfaces + metadata that we can say: I have my table and columns, please use them. Some implementations might require from you additional columns and tables, and some of them will not cope with your schema. Take care when choosing the product
    Reply to this Reply to original

  10. container impacting DB structure?[ Go to top ]

    Well indeed container impacting DB structure. For example if a DB itself implements locking using multiversion concurrency control no one oblige you to create an extra filed in the table! Why not to use kinda helper tables for that.
    DB multiversion concurrency control is a different concept than optimistic locking in an application.
    The first one stays at the Db Transaction level
    The second one is mainly used in conjunction with entity/data reattachment: typically between 2 DB tx.
    Reply to this Reply to original

  11. container impacting DB structure?[ Go to top ]

    I was a bit taken aback by this. Am I the only one amazed to hear that entity beans will require an extra field in the database, for each and every table? This apparently precludes the use of EJB 3.0 entity beans for existing (and unmodifiable) DB schema.

    On a cursory read I’m not sure whether he’s talking about a specific implementation or something that mandated by the spec (can anybody confirm what the contract on Entity Manager in the EJB3 spec is?).

    But at the very least the implementation of Entity Manager can choose to keep versions in the separate table w/o impacting existing tables.

    Regards,
    Nikita.
    Reply to this Reply to original

  12. container impacting DB structure?[ Go to top ]

    Thanks Nikita and Emmanuel for the information. My fault for not being au fait with the spec.
    Reply to this Reply to original

  13. container impacting DB structure?[ Go to top ]

    The version column in the database is only required when using optimistic concurrency according to the early draft EJB 3.0 specification. My apologies for not making that point more clear in the interview. If you would like the specification to include other forms of optimistic concurrency--not version based--be sure to let the expert group know.
    Reply to this Reply to original

  14. Looks good[ Go to top ]

    I really like what I'm hearing about EJB 3.0. It seems to me that they have really drawn upon the best ideas out there. One thing though, how do you think the new POJO entity model will work. Will it still be nearly as performance degrading as entity beans?
    Reply to this Reply to original