Paul Fisher

Distributed transactions are not a primary focus of the book, but Spring is able to work with both local and distributed transactions — without requiring any code changes. This is one of the advantages of Spring: you are able to decouple these types of concerns to a matter of configuration. You can leverage JTA vs a local transaction provider simply by updating your Spring configuration.

--Paul

Hi Anil,

We do cover add-on and integration features for Hibernate, such as using Hibernate-Search, domain to DTO mapping tools, testing frameworks, RIA integration approaches, etc. However, we don't cover Middlegen as this isn't that popular of a solution anymore. I have personally used middlegen in the early days of Hibernate, but it's utility has decreased significantly now that it is so much simpler to define domain objects and customize mapping configurations. This makes mapping to legacy databases much easier. And for those looking to simply generate their schema from scratch, this has become rather simple and seamless in recent versions of Hibernate.

Of course, there are still viable uses for middlegen, but we tried to focus on those technologies that we felt offered the widest range of need for developers.

Please let me know if you have any questions.

Thanks again,

Paul

Hi Gian,

Since our book focuses on strategies for building scalable, production-ready applications, caching strategies are an important topic in our book. It's difficult to give you an accurate answer to your question, as there is no perfect caching strategy. It really comes down to your application's requirements. If you are building an application that will be deployed in a clusterable configuration, you may want to consider a caching implementation that is cacehable. We recommend ehcache, as it supports several clusterable caching configurations, using either RMI, JMS, or jgroups. The advantage of a clustered caching strategy is that it can prevent the potential for stale content, as a clustered application in which each node in the cluster uses its own private cache, an update to the database won't be propagated to the caches of other nodes in the cluster. This can lead to stale content and version conflicts. Additionally, without a clustered caching configuration, you will continue to put additional load on the database, increasing with each node added to the cluster.

More important than the caching provider is how effectively you tune your caching strategy. For instance, selecting the appropriate TTL, cache size, and expiration model can have a dramatic effect on your application's performance. Misusing caching can actually degrade performance, and is a common pitfall. For instance, if you cache too many objects, you will likely run into memory issues or GC thrashing. Also query caching can be an effective optimization or a serious performance problem as well.

Hope this helps!

Paul Tepper Fisher

Thanks for providing the thread, Christophe.

Kevin, I hope that answers your question. Please let me know if you have any further questions about the book's coverage or focus.

Best Regards,

Paul Tepper Fisher, author, Spring Persistence with Hibernate

Hi Christophe,

It wasn't easy! But we tried to focus on topics that aren't covered in other books, without reiterating the documentation of the Spring and Hibernate frameworks (although we do include a good amount of introductory/getting started material, of course).

Thanks again for your comments and feedback on the book. It's been really encouraging to hear your contributions on this forum.

Best Regards,

Paul

Hi Gian,

Our application is an image gallery application, and it covers a good portion of core Spring 3 and Hibernate best practices. Of course, we couldn't cover every aspect we wanted to discuss (we would have needed 5000 pages!). But we do cover those concepts and techniques that we believe are most crucial for succeeding with these two frameworks. As I mentioned in a different post, our primary focus is on developing scalable applications, and we tried to include those strategies we felt were most important. We also tried to highlight potential pitfalls that we have come across ourselves, so that readers of our book can learn from some of our experiences.

Additionally, we included a grails and roo version of our sample application, as well as additional code samples to help illustrate very specific concepts that weren't effectively addressed by the sample application.

Thanks again for your interest in the book!

Best Regards,

Paul Tepper Fisher, author of Spring Persistence with Hibernate

This looks like an exception related to Eclipse and a javascript evaluation process.

Hope this helps,

Paul

Hi Christophe,

Our book also covers strategies for building applications can handle heavy load. Obviously, this doesn't break down to a single topic, but we focus on important scalability concepts, such as caching techniques, load-testing approaches, managing concurrent updates, clustering, querying optimizations, lazy loading, and more. Many of these topics covered in our book are based on our own experiences designing, deploying, and maintaining high-volume websites.

I hope this helps, and thanks for your question.

Best Regards,

Paul Tepper Fisher, author, Spring Persistence with Hibernate

The best reference for grails is the online documentation and the Definitive Guide to Grails, published by Apress.

We also cover Grails and Roo in our soon-to-be-published book, Spring Persistence with Hibernate.

Good luck!

Paul Tepper Fisher

As we mentioned in a different, post we tried to cover those advanced topics that we felt deserved more attention and that are important when it comes to building real-world, scalable applications. Concurrency and locking (along with many others) are both topics that we feel merit attention. Based on the feedback in this forum, it sounds like there is a general consensus on this — so it's really good to hear that there is real interest in learning more about these topics.

Thanks for your question, and I look forward to hearing from you soon.

Best Regards,

Paul Tepper Fisher

Hi Tony,

It's difficult to tell from your question how you have set-up your transaction strategy. Are you using standard spring transactions? If so, do you have a service facade with the transactional rules specified? If the conflict is happening between two different threads, I would recommend having each thread execute its changes within the context of a transaction, and you should then ensure that you are using a very conservative isolation-level.

Within Hibernate, are you using a locking strategy? One simple approach is to use optimistic locking, and ensure that your domain model includes a version field (you can add an integer field and specify @Version to denote a version field). This will allow Hibernate to verify an update by first checking the value of the row in question's version field against the in-memory version before attempting an update. If the version returned by the select doesn't match the version of the in-memory domain object, Hibernate can assume that there is a race condition. You can handle these conditions by catching org.springframework.dao.OptimisticLockingFailureException within a try block, when attempting to modify the contentious domain object.

While optimistic locking is a reasonably effective and performant strategy for concurrent modifications, it isn't ideal for more dynamic scenarios. You can instead employ a pessimistic locking strategy, although this will incur a performance penalty by locking the database table. You should perform locks within the context of a transaction, and either attempt to first load your domain object via a session.get(class, id, LockMode.UPGRADE), or call session.lock(), specifying a LockMode of UPGRADE or READ. Calling lock also forces a version check, so this can help prevent potential race conditions as well.

I hope this helps. Please forward along your domain model and transaction setup if you have further questions.


Thanks,

Paul

Adding to Brian's point, in-memory databases definitely help make it easier for readers of the book to follow along, since there is no real installation process required. However, one of the benefits of Hibernate is its ability to make your application more agnostic to the database vendor. This is another great feature of ORMs in general, and Hibernate allows you to simply select the dialect that matches your database, drop in the appropriate JDBC jars, and you're ready to go! We recommend using in-memory databases for automated testing, while leveraging a more robust database for staging and production. With Hibernate, however, you don't need to worry too much about slight incompatibilities between one database vendor and another. Instead, you can have environment-specific configuration that uses an in-memory DB for local and/or testing scenarios, while using mySQL, postgreSQL, or oracle in Production. So Hibernate provides you with flexibility and portability without requiring additional code complexity to make this happen.

Anyway, thanks again for your comment!

Best Regards,

Paul Tepper Fisher

Our book includes many code samples, most of them based on a sample application that is illustrated over the course of the book. We also include a few variations of the application to offer some contrast on different strategies you can use for building an application. For example, we include Grails and Roo versions that provide a good point of comparison to the more classic Spring 3 and Hibernate approach.

So to answer your question, yes, we do include code samples and there are several chapters dedicated to more advanced topics, such as caching strategies, concurrency techniques, testing, serialization, integration with other frameworks, etc.

Thanks again for your questions!

Best Regards,

Paul

Hi Visu,

Our book covers a little bit of each: we introduce some of the core concepts of both frameworks, but a recurrent theme throughout the book is how to leverage Spring 3 and Hibernate to build a production quality application. There is a strong focus on using best practices and design patterns, and how Spring can help decouple your dependencies, bootstrap your persistence tier, provide declarative transaction capability, etc.

We also introduce some of the newer development frameworks that build upon the foundation of Spring and Hibernate, such as Grails and Roo. We believe that covering these frameworks is important as it helps to provide a comparison of different development strategies, illustrating that there is more than one "best practice" for building a solid application. For instance, the classic Spring/Hibernate approach for developing a persistence tier leverages the DAO and service facade patterns, abstracting your persistence technology and providing clearly defined, transactional business rules/behavior. Grails and Roo, on the other hand, offer an approach that relies more on convention over configuration, reducing persistence tier code by minimizing the need for a DAO, instead leveraging the Active-Record pattern for lower-level persistence operations.

So, I think you will find that we tried to present a range of different strategies for developing a persistence tier using Spring 3 and Hibernate.

The short answer to your question is: sure! One of the missions of Spring's persistence/ORM support is portability, meaning it helps to decouple your selected persistence framework, making a transition to a different strategy far simpler. To help support this portability, Spring provides a generic exception hierarchy (allowing you to handle exceptional conditions without being tied to a persistence framework's classes), a generic transaction strategy, and a consistent approach for querying, batching, updating, etc.

Of course, when you are talking about moving from Hibernate to JPA, the transition is much simpler since these two technologies are very much related. In fact, we discuss JPA in our book, along with the question of when it makes sense to use JPA and when it is better to use Hibernate. We typically recommend the JPA annotations, whenever possible, but some of these "rules" are a bit application-specific.

Thanks for your question, and I look forward to hearing from you soon.

Best Regards,

Paul Tepper Fisher, author Spring Persistence with Hibernate