The public draft of the JPA 2.0 specification is already out and includes a much-awaited feature: an API that lets you create queries by calling methods of Java objects, instead of by embedding JPA-QL into strings that are parsed by the JPA implementation. You can learn more about the API proposed by the public draft at Linda's blog.
If there's one thing that we really want to get right as Web Beans goes from Public Draft to Proposed Final draft, it's integration with the Java EE platform. Up to this point, most of the work we've been doing as an EG was focused on nailing down the programming model, the semantics of the Web Beans services, and the behavior of the Web Bean manager. We've been writing the spec to assume that Web Beans implementations should be pluggable between different Java EE containers, because this is a direction that a lot of folks in the Java EE community believe that the EE platform should move in, and because we would like Web Beans to help show the way for other specifications such as EJB, JTA and perhaps even Servlets (note that JPA and JSF already support this).
Happy Birthday Hibernate! Now that the first copies of Java Persistence with Hibernate are shipping (still waiting for mine though), the first people who should get one are Hibernate contributors. Manning Publications sponsors 25 copies of the book, and we'll distribute them in exchange for 25 Hibernate forum credits. See this page for details.
People using the Criteria API have either transparently or knowingly
used a ResultTransformer .
A ResultTransformer is a nice and simple interface that allows you to
transform any Criteria result element. E.g. you can make any Criteria
result be returned as a java.util.Map or as a non-entity Bean.
A bug report was recently
opened in Hibernate's JIRA stating that Hibernate incorrectly handles deadlock scenarios.
The basis for the report was an example in the /Pro Hibernate 3/ book (Chapter 9). For
those perhaps not familiar with the term deadlock, the basic gist is that two processes
each hold resource locks that the other needs to complete processing. While this phenomena
is not restricted to databases, in database terms the idea is that the first process (P1)
holds a write lock on a given row (R1) while the second process (P2) holds a write lock on
another row (R2). Now, to complete its processing P1 needs to
acquire a write lock on R2, but cannot do so because P2 already holds its write lock.
Conversely, P2 needs to acquire a write lock on R1 in order to complete its processing,
but cannot because P1 already holds its write lock. So neither P1 nor P2 can complete
its processing because each is indefinitely waiting on the other to release the needed
lock, which neither can do until its processing is complete. The two processes are said
to be deadlocked in this situation.
Over the past few months we have been adding some simplifications to
the way you can use and specify native sql queries in Hibernate.
Gavin even blogged about some of them earlier , but I thought it were about time we brought some more news on this blog about it.