Discussions

News: Article: Migrating JDBC DAO to EJB3

  1. Article: Migrating JDBC DAO to EJB3 (68 messages)

    Debu Panda has written "Migrating JDBC Data Access Objects to use EJB3," showing how use of the Java Persistence Architecture can reduce code in DAO construction, create fewer classes, increase portability, and reduce maintenance, using the J2EE Blueprint "Adventure Builder" application as a test.

    Read "Migrating JDBC Data Access Objects to use EJB3."

    Threaded Messages (68)

  2. Doesnt it mean that i have to use a ejb container and not just be happy with a web container like tomcat ?

    Doesnt it mean that I have to understand complexities of ejb 3 instead of simple jdbc calls with some built in transactional support ?

    Havent we burned ourselves in the past with going to EJBs ?

    Did you forget the unending remote exceptions and nights we put in to debug whats going wrong ?

    I guess only place I would think of moving to EJBs is a highly scalable transactional support which simple jdbc cant provide. Although - I like some new frameworks like Spring which still keep it simple for complex transactions.

    Now let the battle begin :).
  3. Shawn:
    Have you ever done any non-trivial project using "simple" JDBC ?

    Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover?

    Have you tried Hibernate3? Are you using Spring?

    Peace.
    Anshuman
  4. Have you ever done any non-trivial project using "simple" JDBC ?
    I have. I used JDBC sometimes, or JDO.
    Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover?
    Well I think you actually mean the "Java Persistence 1.0" spec don't you ? That is what you're referring to here and not EJB3 as a whole. The vast majority of EJB3 doesn't apply to the subject matter.
  5. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Well I think you actually mean the "Java Persistence 1.0" spec don't you ? That is what you're referring to here and not EJB3 as a whole. The vast majority of EJB3 doesn't apply to the subject matter.

    Correct, the article should refer to "Java Persistence API", not EJB3. And actually, the article itself does correctly qualify that...it's just the title of the article that's misleading.
  6. Have you ever done any non-trivial project using "simple" JDBC ?
    I have. I used JDBC sometimes, or JDO.
    Are you comparing JDBC to EJB or EJB with JDO?
    Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover?
    Well I think you actually mean the "Java Persistence 1.0" spec don't you ? That is what you're referring to here and not EJB3 as a whole. The vast majority of EJB3 doesn't apply to the subject matter.
    Actually, I am refering to EJB suite of services including Java Persistence API. Enterprise architecture doesn't stand alone on persistence or ORM framework. It needs much more. Security, trnasaction, dependency injection, concurrency, MOM, remoting, clustering, ... the list goes on.

    These are very potent questions. I asked these questions because, I have seen a lot of time being spent (in this community and elsewhere) without actually understanding the full scope of EJB.

    We compare EJB with Hibernate because ORM used to the weakest(and complex) area of the specification. But when the persistence technology metured and Java Persistence is set to be best of the breed, argument shifts to Spring. One key thing of keeping a specification simple, is to provide the client with solution to most used features first. That's exactly what EJB3 gives.

    -Anshuman
  7. Are you comparing JDBC to EJB or EJB with JDO?
    I'm not comparing anything with anything. You asked what has been used. The fact is that projects should take the relevant technology for the application.
    Actually, I am refering to EJB suite of services including Java Persistence API. Enterprise architecture doesn't stand alone on persistence or ORM framework. It needs much more. Security, trnasaction, dependency injection, concurrency, MOM, remoting, clustering, ... the list goes on.
    so why post against an article that addresses ONLY Java Persistence 1.0 ? Stick to the issue in hand
  8. Shawn:Have you ever done any non-trivial project using "simple" JDBC ?
    Yes. Too many. and they are very flexible and simple to change / debug / deploy etc.
    Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover? Have you tried Hibernate3?
    No. I think its a waste to go cover to cover. Have you ever? The language in the spec isnt always clear and explainatory.
    I have read Servlet and JSP specs and JSR 168 though. But again - not cover to cover. I read it when I need to.
    Are you using Spring?
    Yes. I have used spring for last 1/1.5 years and Hibernate too. They work well and work very well when used together.

    Now that I m dont justifying myself

    Why cant anyone address the issue of complexity in EJB3. ?
    Also why is EJB3 being marketed just for persistence etc these days.? No one is saying anything about what simplicity it brings to table in terms of remote calls.? OR is it still as complex as rocket science ?

    I gave up on EJBs during EJB2 days. Didnt want to waste my time in a cycle of learn - debug - learn again - debug again - feel frustated and then leave it.

    EJB = spec developed by some people who dont know what simplicity is.

    So all the best to EJB users.
    I m happy with tools like spring, web services, jms and "simple" jdbc to get my things done.
    It can do every kind of project - well almost !! Atleast 80% !! For the rest 20% I will figure it out when I get to them. Happy Programming Folks :)
  9. Shawn:
    I would say - read the EJB3 draft.

    Don't get me wrong, I am not against Spring or Hibernate. I have read all the three Rod Johnson's books, been using Spring, Hibernate and TopLink since inception. They solve specific areas and slove it well. But when it comes enterprise solutions you want to have competing implementations. That's why we have standards and specifications. I also read all the EJB specification (cover to cover :)) to keep track of the specifications.

    We need to have comprehensive understanding of problem and solution domain to provide a "right" solution.

    -Anshuman
  10. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Shawn:Have you ever done any non-trivial project using "simple" JDBC ? Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover? Have you tried Hibernate3? Are you using Spring?Peace.Anshuman

    Oh, commmmmmon. I really hope you are not suggesting that one cannot implement a non-trivial project without EJB or Hibernate. Quite frankly, JDBC is so simple that the code to transfer data from DB to in-memory objects is not that much more than the EJB or Hibernate XML code required to do the same mapping. The difference is that JDBC is a lot more straight forward. It's purely personal preference. EJB, Hibernate and Spring have so far failed to make their case to convince developers that they are the next step in software development like Object Oriented Programming was to Procedural Programming.
  11. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Shawn:Have you ever done any non-trivial project using "simple" JDBC ? Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover? Have you tried Hibernate3? Are you using Spring?Peace.Anshuman
    Oh, commmmmmon. I really hope you are not suggesting that one cannot implement a non-trivial project without EJB or Hibernate. Quite frankly, JDBC is so simple that the code to transfer data from DB to in-memory objects is not that much more than the EJB or Hibernate XML code required to do the same mapping. The difference is that JDBC is a lot more straight forward. It's purely personal preference. EJB, Hibernate and Spring have so far failed to make their case to convince developers that they are the next step in software development like Object Oriented Programming was to Procedural Programming.

    Very strong statements, presented like facts, but actually just personal opinions. Very sad ...

    The latest published persistence best practise:
    - move your persistence from domain to DAO
    - combine OR, JDBC SQL and JDBC SP

    OR mapping advantages:
    - caching
    - easy to implement

    Ignoring OR mappings these days is not good idea IMO
  12. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Shawn:Have you ever done any non-trivial project using "simple" JDBC ? Have you read the EJB3 spec. (for that matter, any EJB specs) cover-to-cover? Have you tried Hibernate3? Are you using Spring?Peace.Anshuman
    Oh, commmmmmon. I really hope you are not suggesting that one cannot implement a non-trivial project without EJB or Hibernate. Quite frankly, JDBC is so simple that the code to transfer data from DB to in-memory objects is not that much more than the EJB or Hibernate XML code required to do the same mapping. The difference is that JDBC is a lot more straight forward. It's purely personal preference. EJB, Hibernate and Spring have so far failed to make their case to convince developers that they are the next step in software development like Object Oriented Programming was to Procedural Programming.

    All I am saying is sooner or later, your non-trivial system is going to need a container dealing with systemic issues like pooling, caching, clustering, concurrency, read ahead strategy, fetch joins etc. I hope you are sane enough to deal with that nightmare though JDBC.

    -Anshuman
  13. Given that the Java community has been managing fine with persistence, without using entity beans, why should we start using entity beans now? Also given that EJB3 is partly based on Hibernate3 (or is it the other way around) and there a lot of us using Hibernate, how can I present a business case to my manger to move to EJB3. A business case to move from Hibernate to Hibernate3 would go down better. I've been working on a massively high volume, transactional system and we've done fine without entity beans. How are entity beans going to help me do things better, when things are working very well as they are?
  14. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Given that the Java community has been managing fine with persistence, without using entity beans, why should we start using entity beans now? Also given that EJB3 is partly based on Hibernate3 (or is it the other way around) and there a lot of us using Hibernate, how can I present a business case to my manger to move to EJB3. A business case to move from Hibernate to Hibernate3 would go down better. I've been working on a massively high volume, transactional system and we've done fine without entity beans. How are entity beans going to help me do things better, when things are working very well as they are?

    One way or the other you will move towards EJB3 anyway, because Hibernate is moving towards the EJB3 api via the Hibernat annotations and entity manager.
    As for the rest, how about having the benefits of good tool support multiple vendor implementations while still being able to keep your legacy codebase working (since you are using Hibernate, adding EJB3 is a no brainer to a project once you have moved towards jdk5)
  15. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Given that the Java community has been managing fine with persistence, without using entity beans, why should we start using entity beans now? Also given that EJB3 is partly based on Hibernate3 (or is it the other way around) and there a lot of us using Hibernate, how can I present a business case to my manger to move to EJB3. A business case to move from Hibernate to Hibernate3 would go down better. I've been working on a massively high volume, transactional system and we've done fine without entity beans. How are entity beans going to help me do things better, when things are working very well as they are?

    The business case is:

    a) JPA1(EJB3) API gives you an ability to easily swap from Hibernate to JDO, from JDO to Toplink, from Toplink to Kodo and compare performance and scalability

    b) migration from ejb1/2 to ejb3 is much more easier than to Hibernate

    c) amount of ejb1/2/3 developers is much more higher than Hibernate developers
  16. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Doesnt it mean that i have to use a ejb container and not just be happy with a web container like tomcat ?Doesnt it mean that I have to understand complexities of ejb 3 instead of simple jdbc calls with some built in transactional support ?Havent we burned ourselves in the past with going to EJBs ? Did you forget the unending remote exceptions and nights we put in to debug whats going wrong ?I guess only place I would think of moving to EJBs is a highly scalable transactional support which simple jdbc cant provide. Although - I like some new frameworks like Spring which still keep it simple for complex transactions.Now let the battle begin :).

    It is not about only JDBC or only about CMP(or other OR mappings).

    It is about careful combination of CMP and JDBC SQL and JDBC SP inside of your DAOs to keep your domain model clean and persistence independent.

    Also be aware that you are talking about ejb1 and little bit about ejb2, but the article is about ejb3, which is as simple as Spring IMO ...
  17. DAO is still needed[ Go to top ]

    We are using Hibernate, but we still use DAOs to encapsulate persistence technology. Most of real world applications require a lot of arbitary queries or complex hql-statements and adding that stuff into domain model code looks ugly. Unit testing domain objects is much easier (if you don't have database available all the time) when you can write a stub DAO implementation. And of course, switching persistence technology later (if needed) is easy when DAOs can be replaced and domain code remains the same.

    Technologies like EJB 3.0 and Hibernate surely simplify database access, but I would still create a separate DAO class (unless you are writing a very simple CRUD application).
  18. DAO is still needed[ Go to top ]

    I would still create a separate DAO class (unless you are writing a very simple CRUD application).

    I agree that writing DAOs is still a good idea even with an EntityManager - and if you use a nice generic DAO pattern, you can save a lot of time/repetition by only worrying about your custom queries...not CRUD ops.
  19. DAO is still needed[ Go to top ]

    I don't like DAO, it seems rather "innatural" to me,
    but is's a matter of tast.
    What I would comment here is the statement about unit
    testing: if you use JDO, you don't have to change about
    anything in the code !
    There are a certain number of JDO compliant Java databases:
    Gemstone Facets, PSE Pro, ObjectDB, JDOInstruments on the
    free side.
    You can easily run the vast majority of your functional
    tests with this database, without the need to design a
    relational schema, and then switch to different
    .jdo .<something> configuration files for OR mapping
    if your backend is a RDBMS.

    Guido.

    Oops, forgot to note that if you like EJB3 or JPA or
    whatever name this "new" thing will have you are on
    you own....
  20. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Mr Shawn Spencer,

    If I am not wrong there was an article published in TheServerSide.COM titled "Using EJB 3.0 outside the container"
      
    http://www.theserverside.com/news/thread.tss?thread_id=38910

    cheers
  21. Article: Migrating JDBC DAO to EJB3[ Go to top ]

    Mr Shawn Spencer, If I am not wrong there was an article published in TheServerSide.COM titled "Using EJB 3.0 outside the container" &nbsp;&nbsp;http://www.theserverside.com/news/thread.tss?thread_id=38910cheers
    I know this article. and this is what author says anyway
    One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager; is this a repeat of the same things that bother many developers about past versions of EJB? While surely light frameworks can ease any pain associated with this, should there be an easier (meaning less code, with more self-discovery on the part of the EJB 3.0 container) mechanism for this?
    So isnt it still bothersome to developers ?
  22. One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager;

    I have done a fairly large project with a JDBC DAOs and also I have wirked with EJB2 quite a lot. To be frank I dont really like either way but I'm excited with the Hibernate approach.

    I was hoping EJB3 Entity beans to deliver a simple solution as it is in Hibernate. But why the hell they want us to engage with JNDI lookups for non-container driven applications? For me this seems to be a major conceptual mismatch...

    Hasith Yaggahavita
  23. One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager;
    I have done a fairly large project with a JDBC DAOs and also I have wirked with EJB2 quite a lot. To be frank I dont really like either way but I'm excited with the Hibernate approach. I was hoping EJB3 Entity beans to deliver a simple solution as it is in Hibernate. But why the hell they want us to engage with JNDI lookups for non-container driven applications? For me this seems to be a major conceptual mismatch...Hasith Yaggahavita

    Please, you can use JNDI or public static method to get JDBC data source or persistence manager instance. There is no problem at all, it is up to you. In containers people use JNDI for better managebility. But you can use whatever you want. I do not see "conceptual mismatch" at all

    BTW Hibernate3 implements JPA1(EJB3) API. So days of proprietar Hibernate APIs are counted ...
  24. One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager;
    I have done a fairly large project with a JDBC DAOs and also I have wirked with EJB2 quite a lot. To be frank I dont really like either way but I'm excited with the Hibernate approach. I was hoping EJB3 Entity beans to deliver a simple solution as it is in Hibernate. But why the hell they want us to engage with JNDI lookups for non-container driven applications? For me this seems to be a major conceptual mismatch
    This article does cover migration aspect when you are running in a container. You do not have to do lookup when using Persistence API outside the container. You can create an entity manager from EntityManagerFctory

    EntityManagerFactory emf = Persistence.createEntityManagerFactory("AdventureBuilderPU");
    // create EntityManager
    EntityManager em = emf.createEntityManager();

    See detailed instructions how to use EJB3 Java Persistence outside container using TopLink Essentials (EJB3 RI) in this blog: http://technology.amis.nl/blog/?p=962

    regards
    Debu
  25. The EJB3 Java Persistence API .... lets developers skip the mundane task of building DAO and JDBC code.

    People don't still write DAO code by hand do they? There are some good DAO code generators around these days, such as FireStorm/DAO. Nothing mundane about generating a complete DAO tier in a few seconds from your relational schema.
    Most developers will be using the EJB3 Java Persistence API instead of writing JDBC code with DAO.

    How many people are going to commit to EJB for a third time after being burned twice before? I'm assuming many people will jump directly to SDO or continue using a tried and tested DAO approach.
  26. DAO's are not mundane, if done properly[ Go to top ]

    The EJB3 Java Persistence API .... lets developers skip the mundane task of building DAO and JDBC code.
    People don't still write DAO code by hand do they? There are some good DAO code generators around these days, such as FireStorm/DAO. Nothing mundane about generating a complete DAO tier in a few seconds from your relational schema.
    Most developers will be using the EJB3 Java Persistence API instead of writing JDBC code with DAO.
    How many people are going to commit to EJB for a third time after being burned twice before? I'm assuming many people will jump directly to SDO or continue using a tried and tested DAO approach.


    Basically all who read the specs and have used Hibernate, Toplink Kodo and other ORM mappers in the past. Those who will still cry I was burned by EJB in the past hence I wont read the specs and wont use it, will use the API under a different name (Hibernate Entity Manager and annotations, Java Persistence API) in the future.
    And those who even refuse to do that will have to write their own mappers or go for non Hibernate, Toplink, Kodo etc... alternatives.

    Face it the api is very close to what people who use the named products are used to, the tool vendors are going onto the ship as well as it seems, and a switch from Hibernate to the Entity manager+ annotations is as simples as it could be.

    EJB3 only has a resemblence to the old entity beans in the name, the rest is a pure orm mapper which is state of the art and driven by the best JDO and POJO mappers around.
  27. Annotations question.[ Go to top ]

    Hi, I have not used annotations before and I was wondering;
    If I annotate my POJOs and then use them as transfer objects, do my clients need the EJB class libraries that define these
    annotations?
  28. Performance[ Go to top ]

    I'm just curious to know if there were any noticeable performance differences, assuming you had well written DAOs to begin with.
  29. Performance[ Go to top ]

    I'm just curious to know if there were any noticeable performance differences, assuming you had well written DAOs to begin with.

    That's the first thought I had, too. I'd guess that actually performance might improve, as a commercial persistence manager can employ more highly sophisticated caching than the average programmer can implement in a homegrown DAO layer, thus reducing the number of time-expensive roundtrips to the database.

    On a lighter note, the goose illustration in the title reminded me of the bird flu being all the rage in Germany at the moment. Hopefully, this kind of migration does not introduce hidden but lethal bugs... ;-)

    Cheers, Lars
  30. What about non-trivial SQL?[ Go to top ]

    Do you guys at Oracle do only simple, selection-only statements? Because in this case, Oracle Forms has LOC count of about 500... Not to mention that MySQL would beat any performance test you can create for such a simple usage...
  31. Why would I lock with the Database[ Go to top ]

    May be this is an old discussion but I am kind of new to ejb3. With what i see is that I am locking myself to the database structure in ejb3 with things like

    @Entity
    @Table(name = "SIGNON")

    and

    @Id
        @Column(name="USERNAME")

    now whenever i need to change the structure or table name would i need to RECOMPILE?
  32. Why would I lock with the Database[ Go to top ]

    May be this is an old discussion but I am kind of new to ejb3. With what i see is that I am locking myself to the database structure in ejb3 with things like@Entity@Table(name = "SIGNON")and@Id&nbsp;&nbsp;&nbsp;&nbsp;@Column(name="USERNAME")now whenever i need to change the structure or table name would i need to RECOMPILE?
    If you're using a typical DAO, you'd have to recompile, too. If you have SQL in external files (as in say iBatis), you can't see the mapping from the bean's soruce code. And you're usually "locked" in "database structure" anyway, as having different names for bean attributes than for table columns make even toughest of mainteners break in tears.
  33. Why would I lock with the Database[ Go to top ]

    May be this is an old discussion but I am kind of new to ejb3. With what i see is that I am locking myself to the database structure in ejb3 with things like@Entity@Table(name = "SIGNON")and@Id&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;@Column(name="USERNAME")now whenever i need to change the structure or table name would i need to RECOMPILE?
    If you're using a typical DAO, you'd have to recompile, too. If you have SQL in external files (as in say iBatis), you can't see the mapping from the bean's soruce code. And you're usually "locked" in "database structure" anyway, as having different names for bean attributes than for table columns make even toughest of mainteners break in tears.

    Well, this is one of the most stupid usage of annotations
    (the other one concerns web services, but it is a son of
    WSDL, btw another stupid thing).
    But there are very good (old) news for you !!
    You don't need a typical DAO anymore, if you use JDO.
    If you use mapping file approach you can change your
    relational schema WITHOUT recompiling anything.
    So if, for example, a certain schema works fine with
    oracle but there is a better solution with mysql,
    with JDO2 you can bundle different mapping solution
    in a single jar and decide at runtime wich one to use
    (repeat with me: at runtime).
    And yes, as I said before, if you move from an OODMBS
    to RDBMS, your code doesn't change as well.
    Do you still like annotations ?
    Do you still like JPA ?


    Guido.
  34. Why would I lock with the Database[ Go to top ]

    May be this is an old discussion but I am kind of new to ejb3. With what i see is that I am locking myself to the database structure in ejb3 with things like@Entity@Table(name = "SIGNON")and@Id&nbsp;&nbsp;&nbsp;&nbsp;@Column(name="USERNAME")now whenever i need to change the structure or table name would i need to RECOMPILE?

    You can use XML to define the O-R mapping if you so like.
    Here is what I've in this article

    "The EJB3 Java Persistence API defines O-R mapping using Java metadata annotations or XML descriptors."

    -Debu
  35. Why would I lock with the Database[ Go to top ]

    May be this is an old discussion but I am kind of new to ejb3. With what i see is that I am locking myself to the database structure in ejb3 with things like@Entity@Table(name = "SIGNON")and@Id&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;@Column(name="USERNAME")now whenever i need to change the structure or table name would i need to RECOMPILE?
    You can use XML to define the O-R mapping if you so like.Here is what I've in this article"The EJB3 Java Persistence API defines O-R mapping using Java metadata annotations or XML descriptors."-Debu

    It is somehow meaningful the order of the options:
    first the annotations, then, if you really want to
    suffer and be enough dumb, the XML files.

    IMO, you can't use annotations approach for something
    that is a little more than a toy (or a prototype).
    Let say well, I am not able to use annotation approach.....

    I would recall the golden rule of development by
    prototype approach:
    the first thing to do to implement a system starting
    from a prototype is to throw away the prototype.

    Unfortunately, very savy managers never wrote or
    maintained a line of code and think that this statement
    is totally crazy.
    So you start with a toy and end up with a total mess.

    Good luck.

    Guido.
  36. It a good practice to isolate persistence API calls in a layer, we used to qualify this layer as DAO.
    I don't like the "Data" of Data Access Object pattern.

    Community is trusting more and more on Domain Model design (when needed) because we can easily solve persistence problems with frameworks like Hibernate, Toplink, … and EJB3, Domain Model is Data AND business behaviour using complex object network.

    UnitOfWork pattern (EJB3 Entity Manager, Hibernate Session, Toplink UnitOfWork), is able to handle many sql Insert, update, delete SQL statements only by providing _Persistence by reachability_ and dirty checking features on our object network.

    CRUD is not necessary anymore, this isolation layer is essentially handling READ operations, to obtain a root entity from which you can reach other objects... You don’t have to code any UPDATE, DELETE or INSERT, just delegate to persist, merge, remove methods.

    So DAO becomes EAO (Entity Access Object).
    CRUD becomes PRADR (Persist, Retrieve, Attach, Detach,Remove, knowing that persist, detach, attach, remove is natively done by EntityMaganer, nothing to do!).

    Anthony
  37. I don't like the "Data" of Data Access Object pattern.
    Me neither. I started using PAO (Persistance AO). But I like EAO. BTW, is the pronounced "EOOOOW!" : )
  38. It a good practice to isolate persistence API calls in a layer, we used to qualify this layer as DAO.I don't like the "Data" of Data Access Object pattern.Community is trusting more and more on Domain Model design (when needed) because we can easily solve persistence problems with frameworks like Hibernate, Toplink, … and EJB3, Domain Model is Data AND business behaviour using complex object network.UnitOfWork pattern (EJB3 Entity Manager, Hibernate Session, Toplink UnitOfWork), is able to handle many sql Insert, update, delete SQL statements only by providing _Persistence by reachability_ and dirty checking features on our object network. CRUD is not necessary anymore, this isolation layer is essentially handling READ operations, to obtain a root entity from which you can reach other objects... You don’t have to code any UPDATE, DELETE or INSERT, just delegate to persist, merge, remove methods.So DAO becomes EAO (Entity Access Object).CRUD becomes PRADR (Persist, Retrieve, Attach, Detach,Remove, knowing that persist, detach, attach, remove is natively done by EntityMaganer, nothing to do!).Anthony

    All this has been well analysed and modeled by Scott Ambler
    (http://www.ambysoft.com) many, many years ago.
    And transferred in a formal spec (JDO) many, many
    years ago.

    It is rather funny that Oracle tries to teach us
    how to do the things right after sqlj.

    Guido
  39. All this has been well analysed and modeled by Scott Ambler(http://www.ambysoft.com) many, many years ago.And transferred in a formal spec (JDO) many, manyyears ago.It is rather funny that Oracle tries to teach ushow to do the things right after sqlj.Guido

    i don't really know how your sentence is helping but if you are happy with this, continue...

    The important thing is that EJB spec is much better, isn't it?

    Have you noticed that i have nothing to do with Oracle?

    It's great to talk about layering apps when using EntityManager, what's wrong or so funny about that?
  40. All this has been well analysed and modeled by Scott Ambler(http://www.ambysoft.com) many, many years ago.And transferred in a formal spec (JDO) many, manyyears ago.It is rather funny that Oracle tries to teach ushow to do the things right after sqlj.Guido
    i don't really know how your sentence is helping but if you are happy with this, continue...The important thing is that EJB spec is much better, isn't it?Have you noticed that i have nothing to do with Oracle? It's great to talk about layering apps when using EntityManager, what's wrong or so funny about that?
    I didn't want to be offensive, I am sorry.
    My statements were not addressed to you.
    I wanted simply remind that this approach is well present
    since a long time.
    Now with JPA/EJB3 promotion campaign, Oracle
    (via Toplink) and other (not you) are discoverying
    warm water.

    Again excuse me.

    Guido.
  41. All this has been well analysed and modeled by Scott Ambler(http://www.ambysoft.com) many, many years ago.And transferred in a formal spec (JDO) many, manyyears ago.It is rather funny that Oracle tries to teach ushow to do the things right after sqlj.Guido
    i don't really know how your sentence is helping but if you are happy with this, continue...The important thing is that EJB spec is much better, isn't it?Have you noticed that i have nothing to do with Oracle? It's great to talk about layering apps when using EntityManager, what's wrong or so funny about that?
    I didn't want to be offensive, I am sorry.My statements were not addressed to you.I wanted simply remind that this approach is well presentsince a long time.Now with JPA/EJB3 promotion campaign, Oracle (via Toplink) and other (not you) are discoverying warm water.Again excuse me.Guido.

    Oh guy, no problem, i agree with some points.

    When i look at some Sun Papers about CoreJ2EEPatterns
    http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
    i really think this has nothing to do with REAL object oriented patterns, this is a "how you must do with J2EE" paper.

    I hope Sun is going to update the page and help people avoiding anemic domain model, stop using DTO everywhere (i insist on everywhere),... these 2 anti patterns are evil.
  42. The important thing is that EJB spec is much better, isn't it?

    Yes, it is better, much better. But after getting burned on EJB1 and EJB2, is it any surprise that there's growing support for App Server-independent POJOs.
  43. The important thing is that EJB spec is much better, isn't it?
    Yes, it is better, much better. But after getting burned on EJB1 and EJB2, is it any surprise that there's growing support for App Server-independent POJOs.

    Without EJB1/2 we would not have POJO.

    Everybody is a general after a battle.

    Did we have some better options before EJB1/2???

    It is same think with: servlets -> JSPs -> taglibs -> struts -> JSF

    Nobody hates servlets, everybody hates EJB1/2. Strange ...
  44. Performance??[ Go to top ]

    Article does a good job of explaining the basic functions of EJB 3.0. Like the annotations for specifying a table in the bean itself.
    As a developer, It seems like it would make my life easy.

    But before I jump into something like this,
    First and foremost, I would like to see some benchmark testing results for EJB3 compared to EJB2 on a sample application(like a pet store).

    Given the better performance of JDBC for a multi-table complex sql compared to EJB2 in my experience.

    That should be a good indicator, in my opinion, if it's even worth-while to start thinking about migration my application to an EJB3 framework from JDBC.


    -Enjoy
  45. Performance??[ Go to top ]

    I would like to see some benchmark testing results for EJB3 compared to EJB2. Given the better performance of JDBC for a multi-table complex sql compared to EJB2 in my experience.

    1) You can not compare APIs. You have to compare their implementations. E.g. Oracle CMP2.1 is Toplink. SUN CMP2.1 is JDO. SUN and Oracle CMP3(JPA1) is Toplink. BEA CMP3(JPA1) is Kodo.

    2) IMO performance of EJB2.1 and EJB3(JPA1) implementations from same vendor is going to be same.

    3) BTW TSS published a year ago that BEA CMP2.1 was faster than Hibernate. You know CMP2.1, this evil technology ... :)
  46. Performance??[ Go to top ]

    Is there a similar study for JBOSS?

    Was the test comparing CMP2.1 on Weblogic versus Hibernate on Weblogic?.

    I would like to see some benchmark testing results for EJB3 compared to EJB2. Given the better performance of JDBC for a multi-table complex sql compared to EJB2 in my experience.
    1) You can not compare APIs. You have to compare their implementations. E.g. Oracle CMP2.1 is Toplink. SUN CMP2.1 is JDO. SUN and Oracle CMP3(JPA1) is Toplink. BEA CMP3(JPA1) is Kodo.2) IMO performance of EJB2.1 and EJB3(JPA1) implementations from same vendor is going to be same. 3) BTW TSS published a year ago that BEA CMP2.1 was faster than Hibernate. You know CMP2.1, this evil technology ... :)
  47. Performance??[ Go to top ]

    Is there a similar study for JBOSS?Was the test comparing CMP2.1 on Weblogic versus Hibernate on Weblogic?.
    I would like to see some benchmark testing results for EJB3 compared to EJB2. Given the better performance of JDBC for a multi-table complex sql compared to EJB2 in my experience.
    1) You can not compare APIs. You have to compare their implementations. E.g. Oracle CMP2.1 is Toplink. SUN CMP2.1 is JDO. SUN and Oracle CMP3(JPA1) is Toplink. BEA CMP3(JPA1) is Kodo.2) IMO performance of EJB2.1 and EJB3(JPA1) implementations from same vendor is going to be same. 3) BTW TSS published a year ago that BEA CMP2.1 was faster than Hibernate. You know CMP2.1, this evil technology ... :)

    The BEA article:

    http://www.theserverside.com/news/thread.tss?thread_id=28804

    DF
  48. Performance??[ Go to top ]

    I would like to see some benchmark testing results for EJB3 compared to EJB2 on a sample application(like a pet store).Given the better performance of JDBC for a multi-table complex sql compared to EJB2 in my experience.That should be a good indicator, in my opinion, if it's even worth-while to start thinking about migration my application to an EJB3 framework from JDBC.-Enjoy

    Raghu Kodali did some performance comparisons between Oracle's EJB 2.1 and Oracle's early EJB 3.0 implementation (based on EJB3 Preview) and blogged about this about six months back at http://www.jroller.com/page/raghukodali?entry=comparing_ejb_3_0_and

    regards
    Debu Panda
    Oracle
    http://debupanda.com
  49. Performance??[ Go to top ]

    EJBs will never be as fast as POJOs are. Remote objects cost a lot in terms of performances.
    We will soon read some benchmarks telling us that dot net is 10 times faster. And these mean benchmarks will compare EJB3 vs ASPx.
    Migrating from JDBC to EJB3 is really stupid. It will take a lot of times, will not bring you anything, the application will be slower and you will be tied up to an app server.
    An interesting article would be how to migrate EJB3 from JBoss to Oracle AS.
  50. Performance??[ Go to top ]

    EJBs will never be as fast as POJOs are. Remote objects cost a lot in terms of performances.

    Please stop it.

    0) Believe or not, EJBs are capable of local calls.

    1) Of course that remote call is slower than local call

    2) But EJB21 local call under transactional/security context has similiar/same performance as POJO Spring local call under transactional/security context or POJO EJB3 local call under transactional/security context

    POJO looks like POJO only for developers. How do you think POJO method under transaction/security context is implemented??? In same way as EJB2.1 beans. Wrappers, dynamic proxies, etc ...



    IMO "EJB3/Spring versus EJB2.1" improves your productivity by 20%. It does not affect: performance, scalability, reliability, functionality at all ... Please comment.
  51. Performance??[ Go to top ]

    0) Believe or not, EJBs are capable of local calls.
    Believe it or not - EJBS were not meant for local calls.

    Why would someone go thru EJBs just to make local VM calls.
    Thats the worst use of EJBS - to make local calls.
  52. Performance??[ Go to top ]

    0) Believe or not, EJBs are capable of local calls.
    Believe it or not - EJBS were not meant for local calls. Why would someone go thru EJBs just to make local VM calls. Thats the worst use of EJBS - to make local calls.

    how are you going to call your Spring POJO, EJB3 POJO Session EJB or EJB2 Session EJB under transactional context from servlet??? By local call. And performance? Same in all 3 cases.

    how are you going to call your Hibernate POJO, EJB3 POJO Entity EJB or EJB2 Entity EJB under transactional context from your domain model??? By local call. And performance? Same in all 3 cases.

    Yes, EJB1 did not support local calls, but it is like 6 years ago ...
  53. Performance??[ Go to top ]

    0) Believe or not, EJBs are capable of local calls.
    Believe it or not - EJBS were not meant for local calls. Why would someone go thru EJBs just to make local VM calls. Thats the worst use of EJBS - to make local calls.

    Some people believe that POJOs and EJBs2 are completely different technologies, implemented in completely different way, should be used in completely different way and give completely different performance and scalability.

    IMO Spring/Hibernate/EJB3/JPA1 are ONLY partial improvement of EJB2. Easier to use, but the core is still same. Please comment.
  54. Performance??[ Go to top ]

    0) Believe or not, EJBs are capable of local calls.
    Believe it or not - EJBS were not meant for local calls. Why would someone go thru EJBs just to make local VM calls. Thats the worst use of EJBS - to make local calls.
    Some people believe that POJOs and EJBs2 are completely different technologies, implemented in completely different way, should be used in completely different way and give completely different performance and scalability.IMO Spring/Hibernate/EJB3/JPA1 are ONLY partial improvement of EJB2. Easier to use, but the core is still same. Please comment.

    OK, JPA and persistence issues that started this discussion
    are mixing with EJB ones, so the confusion increases.
    Anyway, until now I believed that POJO was the acronym of
    Plain Old Java Object and was typically used to qualify
    JDO capability to persist objects without inheriting from
    a specific base class.
    Now I learn that POJO concepts is bound to
    Spring/Hibernate/EJB1/EJB2/EJB3/EJBforever/JPA.
    Happy to know it.
    Now I learn that I should use EJB to make local call to
    some Session Stateful/Stateless or Entity (oh my god) or
    Message (oh my god again) bean.
    Take a breath...
    I already told this story in another forum, but is
    better to repeat.
    Few years ago, I met a consultant from a very big J2EE
    container vendor who explained to me that "current trends"
    in EJB development were:
    1. do not split servlet container from ejb container
          a) performances suffer
          b) it is hard to do load balancing and fail over
    2. do not use stateful session bean (they realised that
       there is an obvious duplication with servlet session)
    3. use stateless session bean and ...entity bean.

    Now, the last sentence (about entity beans)is self
    commentable, but..
    do we really need a container to make local calls to
    stateless session bean ?

    There is really someone who can justify the complexity
    of ejb development cycle and the costs of a commercial
    J2EE container to run some stateless session bean ?
    To buy what ?
    I want to remeber to myself first that all the
    J2EE technologies, jta, jndi, jms, can be used outside
    a container.
    So ?

    What is the need to link persistence issues to ejb ones
    as if the any serious development cannot be done in a
    (simpler) different way.

    Once there was another acronym: KISS
    Does it mean anything yet ?

    Guido.
  55. Performance??[ Go to top ]

    I believed that POJO was the acronym ofPlain Old Java Object and was typically used to qualifyJDO capability to persist objects without inheriting froma specific base class.

    I am saying that POJO looks like POJO just for developers. Actually it is implemented by wrapper, dynamic proxy, byte code manipulation, etc. So persitence POJO or POJO under transactional/secuirty context is implemented in same way as EJB21 bean. It just looks like a POJO.

    So saying that POJO call is faster than EJB21 call is not true.
    I learn that I should use EJB to make local call tosome Session Stateful/Stateless or Entity (oh my god) orMessage (oh my god again) bean.

    No, I am saing that EJBs2/3 can make local calls or can be locally called. What is wrong with that?
    1. do not split servlet container from ejb container
    a) performances suffer
    b) it is hard to do load balancing and fail over

    Of course. First low of distribution: do not distribute. Who is saying otherwise???
    2. do not use stateful session bean (they realised that is an obvious duplication with servlet session)

    Was discussed on TSS tha SF Session EJBs21 scale in same way as HTTP session.

    If my domain model is implemented/wrapped by Session and Message beans, why I should move some domain stuff to HTTP session? As I have SF Session bean, which can do same job as HTTP session and also offer passivation, which is not always implemented by HTTP session. And SF S EJBs are HTTP independent.
    3. use stateless session bean and ...entity bean

    you should prefer statelessness over statefullness, but not for any cost. if you want te keep a state (what is quite common) than you will have to keep it in DB or in client, what has some other pros/cons.

    Or for server state you can use HTTP session, but as I stated already there is no big difference between SF Session Bean and HTTP session
    Now, the last sentence (about entity beans)is self commentable, but..do we really need a container to make local calls to stateless session bean?

    You can local call your SL Session EJB21 or your SL Session POJO EJB3 or your Spring POJO let's say from servlets. What you do not understand about this concept? And I stated there is going to be no perfromance/scalability difference.
    There is really someone who can justify the complexity of ejb development cycle and the costs of a commercial J2EE container to run some stateless session bean

    I do not see, how is EJB3 more complex than other enterprise technologies. Especially now with JSF you will just "drag and drop" your JSFs and S EJBs. A CRUD for single table is ready in 20 minutes.

    Some J2EE containers are also free.
    ?To buy what ?I want to remeber to myself first that all theJ2EE technologies, jta, jndi, jms, can be used outsidea container.So ?What is the need to link persistence issues to ejb onesas if the any serious development cannot be done in a(simpler) different way.Once there was another acronym: KISSDoes it mean anything yet ?Guido.

    First of all, Spring is a container in some way also.

    Second of all, EJB3/JPA1 complexity is similar as Spring/Hibernate.

    I do understand your concern here and what you suggest as better option.
  56. Performance??[ Go to top ]

    I do NOT understand your concern here and what you suggest as better option.
  57. Performance?? AND easy to do[ Go to top ]

    I do not see, how is EJB3 more complex than other enterprise technologies. Especially now with JSF you will just "drag and drop" your JSFs and S EJBs. A CRUD for single table is ready in 20 minutes.

    I fully agree with this!

    I'd even say that meta datas with annotation + basic EAO (Entity Access Object ;) ) + finders are faster to write than a CRUD for a 4,5 tables.
  58. Performance?? AND easy to do[ Go to top ]

    I do not see, how is EJB3 more complex than other enterprise technologies. Especially now with JSF you will just "drag and drop" your JSFs and S EJBs. A CRUD for single table is ready in 20 minutes.
    I fully agree with this!I'd even say that meta datas with annotation + basic EAO (Entity Access Object ;) ) + finders are faster to write than a CRUD for a 4,5 tables.

    I was mentioning the GUI CRUD for one table. Let's say insert/update/delete for "product categories". I think you mean JDBC CRUD implementation of your DAO.

    In my case I prefer to generate Entity objects from the DB schema, wrap it by DAO, add some business delegate, create a JSF page and for 1 table I am finished in 1-20 minutes.

    DF
  59. Performance?? AND easy to do[ Go to top ]

    Damian, we are not living in the same world. I do projects that are going on production, I am not doing paperware.
    I do not see, how is EJB3 more complex than other enterprise technologies. Especially now with JSF you will just "drag and drop" your JSFs and S EJBs. A CRUD for single table is ready in 20 minutes.
    This is only theory.
    I will not consider EJB3 and JSF as mature enough to go on production.
    Moreover any new technology cost a lot : we have to train developpers and we have to face new troubles.
    So when a new technology comes, I always wonder : why should we use it?
    And for EJB3, I still wonder why.
  60. Performance?? AND easy to do[ Go to top ]

    I will not consider EJB3 and JSF as mature enough to go on production.

    EJB 3 isn't even out yet as a finished standard, so is not production ready. However, JSF certainly is - I am using it for substantial projects.
    Moreover any new technology cost a lot : we have to train developpers and we have to face new troubles.So when a new technology comes, I always wonder : why should we use it?

    You don't have to. But much of this new technology is a real cost-saver. I have found JSF to be much faster to develop with than Struts, so there is a significant saving on development costs for new projects. High-quality ORMs like JDO 2.0 and EJB 3.0 can save a considerable amount of cost as against a vendor-specific non-portable solutions given certain sets of requirements. (I have recently had to deal with a project where a developer went for direct JDBC as against (as I advised) Hibernate or JDO. This resulted in considerable extra expense when the project had to be migrated to a different database).
    And for EJB3, I still wonder why.

    Because EJB3 represents a significant simplification of earlier approaches. This saves time and money. There may be training costs, but this should be more than recovered.

    Also, EJB 3.0 persistence is based on well-established and thoroughly tested approaches that have been used successfully by thousands of developers - Hibernate, TopLink, JDO.
  61. Performance??[ Go to top ]

    Well, a definition of enterprise technology here would help.
    Anyway,
    if
    Of course. First low of distribution: do not distribute. Who is saying otherwise???
    why wrap something in an EJB ?

    To be really access-technology independent, not only HTTP,
    I would code my domain objects as normal Java objects.
    Then I would put a Servlet/JSP/xxx application around to handle
    presentation in a web context.

    Was discussed on TSS tha SF Session EJBs21 scale in same way as HTTP session.
    I am sure that this is true, but if you have 10.000 EJB SF Session
    you cannot avoid 10.000 HTTP Session too.
    I think that's a little overhead, don't you ?
    Again, to buy what ?

    Why, speaking of persistence we end up speaking of EJB tout-court ?

    I don't think that the two problems are bound together.

    Guido
  62. Performance??[ Go to top ]

    Well, a definition of enterprise technology here would help.Anyway,if
    Of course. First low of distribution: do not distribute. Who is saying otherwise???
    why wrap something in an EJB?

    1) wrapping by EJBs does not mean remote calls
    2) wrapping is used in EJB21 if your domain objects are real POJOs (no wrappers, dynamic proxies, byte code manupulation, real pure JAVA objects). when you want to add the transactional and security context to your domain model. this teachnique with EJB3 is unnecessary
    To be really access-technology independent, not only HTTP,I would code my domain objects as normal Java objects.Then I would put a Servlet/JSP/xxx application around to handle presentation in a web context.

    well, you can not do it as your domain stuff must be in some way transaction and secuirty aware (if you are not going to write it by your self). So they must be Spring POJOs (XML descriptors) or EJB3 POJOs (XML descriptors or annotations). So you can unit test them as POJOs, but without Spring or EJB3 container they will not work. So in some way your domain objects must be aware/dependent of enterprise container.
    Was discussed on TSS tha SF Session EJBs21 scale in same way as HTTP session.
    I am sure that this is true, but if you have 10.000 EJB SF Sessionyou cannot avoid 10.000 HTTP Session too.I think that's a little overhead, don't you?

    this was measured in this article and was not found a measurable difference. and you have passivation and HTTP independence. if I go with EJB3/2 I will go for SF EJB.
    Again, to buy what ?
    you do not need to buy them
    Why, speaking of persistence we end up speaking of EJB tout-court?I don't think that the two problems are bound together.Guido

    maybe because JPA1 is just an improvment of CMP Entity EJB21
  63. Performance??[ Go to top ]

    Well, to see my points, it is important to keep in mind
    all the aspects of the little story I told.
    1. Servlet and EJB in the same container
    2. 99.99999999999999999999999% (or more) of EJB access
       are made by servlet apps.

    About security.
    If the above assumptions are true (expecially 2.), you
    already have security layer on servlets.
    And I think you have read 101 EJB damnations too.

    About SF overhead.
    In a web context, servlet layer acts as client projection
    on the server side using a certain application, in broad sense.
    It is quite common that client applications, swing or swt,
    have some local data used for the purposes of client
    behaviour.
    In web context, these local data are naturally put in a http
    session, because servlet layer should mimic a client
    application.
    Having sessions, bound to clients, in the EJB layer may
    be useful for classes of applications (quite limites IMO),
    but cannot be a paradimg for "enterprise applications".
    On the other hand, SL beans are too limiting and the
    benefits (?) cannot justify the development cycle complexity.

    About transaction boundaries.
    First Session Beans are kindly requested to use BMT style.
    1. SL should (better must) start and complete the transaction in the same method invocation. It is your code.
    2. SF can use the same txn in multiple invocation, but,
    recalling point 1, you can hold transaction ref in "client
    application". Again, it is your code that starts and completes a transaction.

    Summarizing, an approach like:
    1. Persistence as POJO (JDO/JPA)
    2. Business logic as POJO using JTA

    can accomplish, essentially, the same job with less effort, better testability and much higher freedom in the design.

    Again, why it is useful to put POJO persistence together
    with EJB (session beans, entity as originally designed are
    universally considered as something to forget).
    To gain what ?

    Guido
  64. Performance??[ Go to top ]

    EJBs will never be as fast as POJOs are.
    That comment is utter nonsense, because pojos are only pojos because some kind of runtime weaving mechanism is woven around. Hibernate in this case uses a proxy which adds the glue code, Toplink uses bytecode alteration.
    Remote objects cost a lot in terms of performances.

    You are mixing two things here, EJB session beans can be local or remotely called, in a local call the overhead
    of a session bean and a spring bean is pretty much the same.
    But that does not have anything to do with what is discussed here, in this discussion we talk about the orm part of ejb3 which sort of is a toplink/hibernate/jdo with a different name and a unified api.
    We will soon read some benchmarks telling us that dot net is 10 times faster. And these mean benchmarks will compare EJB3 vs ASPx.Migrating from JDBC to EJB3 is really stupid. It will take a lot of times, will not bring you anything, the application will be slower and you will be tied up to an app server.An interesting article would be how to migrate EJB3 from JBoss to Oracle AS.
    Well first of all, it depends, in .Net you get total windows lockin, good luck by moving to mono, they lockin is way heavier than moving from one app server to the other.
    Secondly, I see the EJB3 substantially full enough so that you can avoid this lockin entirely, and you do not even have to use a j2ee container, given the fact that there already are embedded implementations. The Persistence part is as container agnostic as any other ORM layer, the session bean part is not, but you can get implementations which do not need a container at all (jboss has one afair)

    It is all a matter of brain 1.0 if you use special stuff from the container vendor, you are locked in, but you do not have to use that stuff, the api is rich enough.
  65. Performance??[ Go to top ]

    Werner, I was surprised your comment.
    Maybe my post was not clear enough.
    You are mixing two things here, EJB session beans can be local or remotely called, in a local call the overhead
    of a session bean and a spring bean is pretty much the same.
    I do not compare EJB3 to Spring/Hibernate but to simple JDBC (with the DAO design pattern).
    I do not use Spring, sometimes Hibernate. I use only database transactions thru JDBC.
    EJBS produce a lot of overhead that cost a lot in terms of performances. All the benchmarks have shown this issue with EJBs. And I don't expect EJB3 to solve that problem. Maybe I am wrong?
    It is all a matter of brain 1.0 if you use special stuff from the container vendor, you are locked in, but you do not have to use that stuff, the api is rich enough.
    Try to migrate EJBs from one app vendor to another, that is not very easy, even if you stick to the API. There was an interesting article on TSS about this kind of migration, but sorry, I can not find it anymore.
  66. Performance??[ Go to top ]

    Werner, I was surprised your comment.Maybe my post was not clear enough.
    You are mixing two things here, EJB session beans can be local or remotely called, in a local call the overhead of a session bean and a spring bean is pretty much the same.
    I do not compare EJB3 to Spring/Hibernate but to simple JDBC (with the DAO design pattern).I do not use Spring, sometimes Hibernate. I use only database transactions thru JDBC.EJBS produce a lot of overhead that cost a lot in terms of performances. All the benchmarks have shown this issue with EJBs. And I don't expect EJB3 to solve that problem. Maybe I am wrong?
    It is all a matter of brain 1.0 if you use special stuff from the container vendor, you are locked in, but you do not have to use that stuff, the api is rich enough.
    Try to migrate EJBs from one app vendor to another, that is not very easy, even if you stick to the API. There was an interesting article on TSS about this kind of migration, but sorry, I can not find it anymore.

    As for the performance, my personal experience is, that by using orm mappers you usually lose performance, but usually you have a plain sql/jdbc fallback for critical parts, so the average app ends up with being around 95-99% orm based and a handful of jdbc fallbacks for the performance bottleneck parts.
    It also depends on how you use the orm mapper, I tend to use lazy loading per default (as Hibernate does since 1.3) because the performance / mem footprint ratio is way better, for the performance tradeoff you get a way better mem footprint, and in many cases you can live with the performance tradeoff.

    Using pure JDBC is a no option for me, as others have pointed out, once things become bigger you have a maintenance nightmare on your hands.
  67. Migrating EJB3 to SDO[ Go to top ]

    Oracle has also signed up for Service Data Objects. Perhaps they will soon be writing article on how to migrate from the EJB 3 API to the SDO API?
  68. Migrating EJB3 to SDO[ Go to top ]

    Oracle has also signed up for Service Data Objects. Perhaps they will soon be writing article on how to migrate from the EJB 3 API to the SDO API?
    You probably do not understand difference between EJB3 Persistence API and SDO specification. Here is a blog by Mike Keith, EJB3 co-spec that outlines the difference between these specifications

    http://jroller.com/page/mkeith

    regards
    Debu
  69. Migrating EJB3 to SDO[ Go to top ]

    Oracle has also signed up for Service Data Objects. Perhaps they will soon be writing article on how to migrate from the EJB 3 API to the SDO API?
    You probably do not understand difference between EJB3 Persistence API and SDO specification. Here is a blog by Mike Keith, EJB3 co-spec that outlines the difference between these specificationshttp://jroller.com/page/mkeithregardsDebu


    I think you missed my point ....

    For the record, CodeFutures supports a very wide range of data persistence technologies - EJB CMP, JDO, JDBC DAOs, SDO, etc... So yes, I do know the difference.