Presentation: The new EJB 3 Persistence API

Discussions

News: Presentation: The new EJB 3 Persistence API

  1. TSS and the Belgium Java Users Group have partnered to bring you an online presentation from one of their recent JUG meetings, hosted exclusively on TheServerSide.com.

    EJB 3 Co-spec lead Mike Keith and SolarMetric CTO Patrick Linskey present "The New EJB 3.0 Persistence API", which goes into detail on the new EJB 3 entity model.

    Watch The new EJB 3 Persistence API

    Threaded Messages (31)

  2. great work[ Go to top ]

    Congrats on both parties for this new partnership.

    The BeJUG has been very successful in providing high quality resource for java addicts in Belgium and the surrounding neighbourhood. With JavaPolis they are serving the best conference on a European scale almost in my back yard. Thanks, Guys !

    Keep up the good work !

    regards,
    Tom Baeyens.
  3. TSS and the Belgium Java Users Group ....</a>

    BeJUG Rules! Is that next to Amsterdam? 2 reasons to go to Javapolis.

    This is the Hibernate based EJB?
    So if you comapre EJB 3 to what they do at Plone or PHP (TikiWiki, Drupal, etc) or .NET(mostly stored procs) or Ruby or XYZ...

    What is the advanatange?

    .V
    (My opinion J2EE has the best DAO, Apache iBatis and example MVC in iBatis PetStore)
  4. So if you comapre EJB 3 to what they do at Plone or PHP (TikiWiki, Drupal, etc) or .NET(mostly stored procs) or Ruby or XYZ...What is the advanatange?.V(My opinion J2EE has the best DAO, Apache iBatis and example MVC in iBatis PetStore)

    Java is usually easier to maintain than PHP, but I love PHP products like Drupal. I hope JSR 223 moves along faster. I'd like to see more integration of PHP and Java.
  5. EJB3 != Hibernate[ Go to top ]

    This is the Hibernate based EJB?

    Hopefully, I'm just falling for some flame bait, but for the record, EJB3 is in fact its own thing. This topic has been beaten to death here (Mike Keith's blog) and here (tss.com), so hopefully we won't need to revisit the topic again in this thread.

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  6. I think Hibernate can support EJB3.0 persistence.(Qiwei Yin)
  7. EJB 3 for TSS[ Go to top ]

    Floyd,

    Does TSS intend to implement their back-end using jBoss 4 + EJB 3 and share their experience with the community (like you guys did with other app servers and .NET)?

    Thierry
  8. Hello,

    can somebody with a little more understanding of the new spec help me with an interpretation of the following statement from page 8 of the slide show:

    "state change automatically synchronized with database"

    Does this mean that state changes are automatically detected (i.e., no more session.update(object))? If so, how is change detection done? I thought this was only possible for (byte-)code generating engines?

    thanks,
    christian
  9. Hello,can somebody with a little more understanding of the new spec help me with an interpretation of the following statement from page 8 of the slide show:"state change automatically synchronized with database"Does this mean that state changes are automatically detected (i.e., no more session.update(object))? If so, how is change detection done? I thought this was only possible for (byte-)code generating engines?thanks,christian

    Someone please correct me if I'm wrong, but EJB3 uses dynamic bytecode generation, which takes place at runtime.
  10. but the spec allows @access="property" annotations, which to my understanding will cause the persistence engine to use property accessors provided by the bean implementor. That and the fact that I use plain POJO objects (and not framework-generated subclasses) prohibits transparent state management IMO. What am I missing?
  11. Hibernate does automatically detect state changes and updates the DB, when it flushes the session. It's done by comparing the original state of each entity to its current state. So, no bytecode manipulation is done.

    I believe Toplink uses the same mechanism.
  12. Someone please correct me if I'm wrong, but EJB3 uses dynamic bytecode generation, which takes place at runtime.

    The spec does not mandate any particular approach. It might be deploy-time sourcecode or bytecode generation or instrumentation or runtime bytecode generation or instrumentation.
  13. Someone please correct me if I'm wrong, but EJB3 uses dynamic bytecode generation, which takes place at runtime.
    The spec does not mandate any particular approach. It might be deploy-time sourcecode or bytecode generation or instrumentation or runtime bytecode generation or instrumentation.

    Don't forget proxying....
  14. Hello,can somebody with a little more understanding of the new spec help me with an interpretation of the following statement from page 8 of the slide show:"state change automatically synchronized with database"Does this mean that state changes are automatically detected (i.e., no more session.update(object))? If so, how is change detection done? I thought this was only possible for (byte-)code generating engines?thanks,christian

    AFAIK, all credible ORM persistence engines on the market today have exactly the same approach here:

    (1) automatic dirty checking of managed objects associated with the persistence context

    (2) some operation (an explicit call) to import changes made to a detached object into the persistence context (Hibernate's update() or merge() operations, or EJB3's merge() operation)

    It is most certainly not true that automatic dirty checking requires bytecode tricks.
  15. But what about when non-Java applications are sharing the database? How about when non J2EE Java applications share the database? The problem with persistence layers that are above the database is that their controls and management are bypassed by legacy apps and apps implemented in other technologies like .NET or C. Does EJB 3.0 fix that? I don't believe it can. It requires too much integration with each data source.
  16. Concurrency Checking[ Go to top ]

    The state change really does only work with J2EE apps as you note. But even going back to the 'old days' of mainframes and TP monitor vs. batch environments this has always been an issue. Clustered applications have had this problem also (unless there is a 3rd party cache shared by the clustered servers). The 3 COMMIT options that have been in the EJB spec since EJB 1 acknowledge this. The best that can be done (for throughput) is to use the concurrency checking utilised by the @Version annotation.
  17. Concurrency Checking[ Go to top ]

    The state change really does only work with J2EE apps as you note. But even going back to the 'old days' of mainframes and TP monitor vs. batch environments this has always been an issue.

    Exactly -- the state change detection is there to prevent the developer from having to tell the implementation what has been done in a current transaction, not to notify the app of changes that happened in other transactions.

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  18. It's an unbeliveable, that couple of guys still don't ever touch CURRENT EJB Containers before criticise the FUTURE containers. From Weblogic 8.1 doc:

    (http://e-docs.bea.com/wls/docs81/ejb/ejb11.html#1122435)

    db-is-shared

    The db-is-shared element applies only to entity beans. When set to true (the default value), WebLogic Server assumes that EJB data could be modified between transactions and reloads data at the beginning of each transaction. When set to false, WebLogic Server assumes that it has exclusive access to the EJB data in the persistent store.

    RTFM!
  19. This doesn't actually solve the problem he states. If another app changes the row half way through his transaction, this setting won't help. (And maybe he doesn't use Weblogic so wouldn't know about it anyway)

    As has been stated before, optimistic locking (which is as old as the hills) is the safest way round it.

    Kit
  20. This doesn't actually solve the problem he states. If another app changes the row half way through his transaction, this setting won't help. (And maybe he doesn't use Weblogic so wouldn't know about it anyway)As has been stated before, optimistic locking (which is as old as the hills) is the safest way round it.Kit

    Exactly, which is why middle tier caching schemes have so little value. Why cache what the DBMS is already caching anyway? Most DBMS's cache SQL and data and many cache resultsets.

    Anyone who thinks that any database of consequence will always exclusively be accessed by J2EE apps hasn't been in IT very long.

    What I really want is good declarative O-R mapping that I can customize and which saves me a lot of typing. I also want all my O-R operations, SQL etc. behind an interface so they don't gunk up the application logic and complicate maintenance.
  21. Exactly, which is why middle tier caching schemes have so little value. Why cache what the DBMS is already caching anyway?

    I can only think of four reasons:

    1) Save millions of dollars
    2) Make the application perform must faster
    3) Handle many more concurrent requests
    4) Achieve higher levels of availability

    Other than that, in my experience, you are correct. ;-)

    On the other hand, as I've said before, most applications can get away with a java.util.Hashtable as their cache, because most applications don't cluster, and even if they do cluster, most of their "bang for the buck" caching will come from reference data that rarely changes.

    When that's not enough, there are a gaggle of great solutions from open source to high-end enterprise solutions available (see sig ;-).

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  22. I can only think of four reasons:1) Save millions of dollars2) Make the application perform must faster3) Handle many more concurrent requests4) Achieve higher levels of availabilityOther than that, in my experience, you are correct. ;-)
    You've missed my point I believe. First of all you are making assertions about savings, performance and availability that are false in the context we are speaking about. I also do not favor hash table or other heap resident caches. There are a number of nice caching solutions especially those outside the JVM that allow sharing across JVMs or even across systems. That part is easy and I don't need EJB 3, Hibernate or Entity Beans to do that. I don't want them to do that in most cases. Let me solve that problem in other ways where I can account for my entire architecture.

    Caching objects, as you point out is fine for nonvolatile data. Doh! The problem is that it does not do much for you when the data is changing often, especially when the data is being changed via mulitple technologies. The DBMS's own mechanism and XA (when data is in more than one place) give the DBMS the ability to preserve data integrity during transactions when different technologies share its data. Maybe if these cacheing solutions were XA resources accessible to non-J2EE apps this problem could be solved. EJB3, et al do not help at all in this regard because they are not aware of the activity of non-J2EE apps. Believe it or not, most of the world's apps are non-J2EE. Doh!

    Java is great but the sun does not shine out of its JSR and other technologies are not going away!

    It would be nice if the DBMS vendors would support a standard so that objects could subscribe to change events on the data they are mapped to. But that hasn't happened. In the meantime, I am satisfied if these persistence tiers such as EJB3, TopLink, Hibernate, JDO et al just give me good O-R mapping tools. It would also be nice if the compiler was smart enough to do the byte code manipulation/augmentation based on hints/annotations instead of a separate step so I could avoid breaking encapsulation with getters and setters for everything.

    As an aside, the best boost I've gotten with caching objects - it was a long running transaction with a lot of statefulness - was when using ObjectStore/Javlin with a J2EE appserver. It has a nice distributed cache and the API that JDO is probably based on. They do straight JDO now to. Performance gains were huge - more than a couple orders of magnitude. The problem then as now is that once you write to your RDBMS and make the data available to the world, things get difficult.

    (No I don't work for ObjectStore and never have.)
  23. It would be nice if the DBMS vendors would support a standard so that objects could subscribe to change events on the data they are mapped to. But that hasn't happened.

    Excellent point! And it isn't an impossibility .. through some major financial services organizations, we've already started the ball rolling on that exact goal. There's at least one major RDBMS vendor quite interested in this as well.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  24. encapsulation[ Go to top ]

    It would also be nice if the compiler was smart enough to do the byte code manipulation/augmentation based on hints/annotations instead of a separate step so I could avoid breaking encapsulation with getters and setters for everything.

    I know at least EJB3 and Hibernate do not force you to have getters and setters.
  25. Anyone who thinks that any database of consequence will always exclusively be accessed by J2EE apps hasn't been in IT very long.

    Well, I've been in 10 years, and I've worked on systems that are accessed exclusively by J2EE apps. This is not counting the obvious(DBAs, maintainence, etc). This is data for the application that is done ONLY by the J2EE application.
    That app was a major application for a major wireless company.

    I've also worked on systems where systems other than J2EE apps can access and change the data.

    So basically, I don't agree with the statement above.
  26. automatic dirty checking[ Go to top ]

    ok, if get that right, this means that any framework that uses this approach will take a snapshot of every managed object when it enters the persistence context, and compare it with the current state field-by-field upon transaction commit. Sonds like a lot of overhead to me, in particular when it comes to large numbers of (managed, but possibly not even modified) objects.

    Wouldnt an event-based solution (e.g., where the entities advertise their being modified from within the mutator methods) provide significant advantages in this respect? I dont want to open the bytecode manipulation can-of-worms here, I am just curious..

    chris
  27. automatic dirty checking[ Go to top ]

    ok, if get that right, this means that any framework that uses this approach will take a snapshot of every managed object when it enters the persistence context, and compare it with the current state field-by-field upon transaction commit. Sonds like a lot of overhead to me, in particular when it comes to large numbers of (managed, but possibly not even modified) objects.

    Consider the alternative. Without taking snapshots you have to do Java synchronization through transactional read/write locks. Having been a user of systems that use synchronization and also an implementor of Entity bean locking strategies, the Hibernate/EJB3 approach scales *MUCH* better. Debugging is a nightmare when you mix application server level locks and DB locks.

    Remember, its easy to scale if your bottleneck is the CPU. Not so easy to scale if there is a lot of lock contention.
    Wouldnt an event-based solution (e.g., where the entities advertise their being modified from within the mutator methods) provide significant advantages in this respect? I dont want to open the bytecode manipulation can-of-worms here, I am just curious..chris

    I don't know the internals of Hibernate that well, but I think Gavin already talked about this on the thread. Bytecode weaving or even proxying can be done for dirty checking.
  28. automatic dirty checking[ Go to top ]

    I dont really understand what role locking and synchronization play in this respect. My point was about the fact that copying the state of, say, hundreds of objects, and later comparing every single one of them seems extremely inefficient in comparison to a scheme where an event is fired when an objects property changes, identifying not only the object, but also the particular property.

    In my opinion, the EJB3 spec does not leave room for the latter kind of dirty checking. The entity classes are plain POJOs under the control of the application (no generated subclasses) - so where would the triggering of change events happen, unless JDO-style bytecode manipulation (detecting every place where the field is assigned to) was performed.

    chris
  29. automatic dirty checking[ Go to top ]

    My point was about the fact that copying the state of, say, hundreds of objects, and later comparing every single one of them seems extremely inefficient in comparison to a scheme where an event is fired when an objects property changes, identifying not only the object, but also the particular property.
    Actually, in real life, in does not really significantly improve your overall performance including for hundreds of objects.
    In my opinion, the EJB3 spec does not leave room for the latter kind of dirty checking. The entity classes are plain POJOs under the control of the application (no generated subclasses) - so where would the triggering of change events happen, unless JDO-style bytecode manipulation (detecting every place where the field is assigned to) was performed.chris
    Bytecode enhancement is a way and like I said, full dirty checking is certainly not a showstopper. Seems pretty enough rooms left by the spec, no?
  30. automatic dirty checking[ Go to top ]

    ok, if get that right, this means that any framework that uses this approach will take a snapshot of every managed object when it enters the persistence context, and compare it with the current state field-by-field upon transaction commit. Sonds like a lot of overhead to me, in particular when it comes to large numbers of (managed, but possibly not even modified) objects.

    Wouldnt an event-based solution (e.g., where the entities advertise their being modified from within the mutator methods) provide significant advantages in this respect? I dont want to open the bytecode manipulation can-of-worms here, I am just curious.

    Chris, there are only two correct solutions:

    1) Pessimistic concurrency -- using database locks to prevent other transactions from changing the data

    2) Optimistic concurrency -- using checks at the end of the transaction to make sure that other transactions have not changed the data

    Events can be a handy way to make optimistic concurrency more likely to succeed when caching is used, but events by themselves will result in data corruption, because there is a "window" of time between when the transaction triggers the event and when the various consumers of the event receive and process it.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  31. Presentation tool[ Go to top ]

    Does anybody know, which tool was used to generate this astonishing presentation? I meen it's obvious that Flash is used to play it and there also has to be a server-side component (maybe Flex) that provides the data as the .swf file is only 1k large, but how exactly does it work, how much effort is it to convert a ppt file and a recorded speech into such a cool online presentation and what software licenses are needed?
    Thanx a lot
    Cheers René
  32. Flash player[ Go to top ]

    The flash player BeJUG and JavaPolis uses is called Articulate. It allows you to add audio to each slide within powerpoint and publish/ftp it to a webserver. You need no server side engine, just a flash enabled browser and a webserver will do. It takes about 1,5 till 2 hours of editing for a one hour talk.

    FYI - You can find more JavaPolis talks using this player @
    http://www.javapolis.com/confluence/display/JP05/JavaPolis+2004+talks

    Enjoy,

    Stephan Janssen
    ------------------------
    JavaPolis 2005 from December 12th till 16th... there is no spoon !