If you haven't done a lot of work with databases, in particular what I'd call "low-level" work on tuning the performance of databases in an enterprise environment, then it's possible that you've never really given much thought to the problems of locking and concurrency. Yet, these are fundamental to the reliablility of database transactions. As Carol says:
Locking is a technique for handling database transaction concurrency. When two or more database transactions concurrently access the same data, locking is used to ensure that only one transaction at a time can change the data.
Sounds simple enough, right? But, it's not quite that simple, because a single method for performing locking may work well under some conditions, and poorly under others. Carol explains:
There are generally two locking approaches: optimistic and pessimistic. Optimistic locking assumes that there will be infrequent conflicts between concurrent transactions, that is, they won't often try to read and change the same data at the same time. In optimistic locking, the objective is to give concurrent transactions a lot of freedom to process simultaneously, but to detect and prevent collisions. Two transactions can access the same data simultaneously. However, to prevent collisions, a check is made to detect any changes made to the data since the data was last read.
Pessimistic locking assumes that transactions will frequently collide. In pessimistic locking, a transaction that reads the data locks it. Another transaction cannot change the data until the first transaction commits the read.
It's all about the likelihood that someone (or some application) that accesses a data element will update the element, and the frequency with which those updates occur with respect to the access times and the total number of updates. If at a given time, 100 people may request access to a data element, but only one of them will seek to update it any time soon, then pessimistic locking is more efficient. Few requests to update the data element are expected, so it is very likely that when that one person chooses to update the element, it won't have changed from what it was before.
Why do we care? Well, locking and unlocking data elements consumes time and processing power. The database application will be able to support fewer concurrent users if the most efficient method for locking and enabling concurrency is not applied.
Carol summarizes locking support in JPA 1.0, and identifies the additional locking support that is implemented in JPA 2.0. For example, JPA 2.0 adds five new lock modes (including the first support for pessimistic locking). The new lock modes are:
OPTIMISITIC
OPTIMISTIC_FORCE_INCREMENT
PESSIMISTIC_READ
PESSIMISTIC_WRITE
PESSIMISTIC_FORCE_INCREMENT
This post would be too long if I went into the details that differentiate these lock modes, and covered additional details of what's in JPA 2.0. But, of course, I don't have to do that, since you can find it all in Carol's article!
Formally (at least going by its URL address), Carol's Enterprise Tech Tips site is a blog. But, in just about every case, I'd call her entries more full-fledged technology articles than blog posts. They're insightful, well-structured, detailed tutorials on currently relevant topics in enterprise Java software engineering. Always a great read, and an excellent reference on the topic at hand.
The Java Persistence API (informally referred to as JPA) provides a plain old Java object (POJO)-based persistence model for Java EE and Java SE applications. It handles the details of how relational data is mapped to Java objects, and it standardizes Object/Relational (O/R) mapping. The latest update to JPA, Java Persistence 2.0, adds a number of new features such as additional O/R mapping functionality and new query language capabilities. Another area that has been enhanced in JPA 2.0 is locking and concurrency...
Fuctional programming has existed for decades, but only in the last few years has it gained the attention it deserves, for a lot of very good reasons like:
it reduces code duplicarion
it improves readability
it allows better reuse
it facilitates multi-threading programming
it eliminates ugly programming by side-effects ...
GlassFish v3 is available in a number of download bundles. The bundles are available at different locations: the Community Download Page and the JavaEE Preview SDK, with different installer technologies: ZIP file or an installer and with different feature sets: Web or Full Profile...
A new Java Power Tools Newsletter is out! In this issue, we study the theory and practice of Mock Objects, including the subtle differences between mocks and stubs, and a simple case study using Mockito, the new kid on the block of Mock Objects frameworks for Java...
The GlassFish Mobility Platform team has been working on many new features since the 1.1 release back in February 2009, one of which is adding support for MCBO on the Java SE platform. This will allow the development of desktop synchronization clients that are much more powerful than their mobile Java ME siblings...
In a previous post : PART2 I describe how to run JSP over Grizzly. Now I'll show you how to run PHP over Grizzly. here a sample web.xml file for PHP support. (I'm using Quercus, but you could use native PHP too)...
In the Forums, skalabic asks Can you make playDialogSound() public?: "Hello, can you make playDialogSound() from display class public? I don't see why it should be private only and would like to use it from my application, not when displaying dialog only..."
mbazs has issues with Glassfish and JMX: "Hi, I'm new to JMX, but I didn't manage to understand how it is going in J2EE/GF. I would like to deploy my EAR, that contains an EJB, servlets and so on. My question is how could I make this manageable? For example, I'd count..."
And bennyk asks about A "Soft" Human Interface Device over Bluetooth?: "I am exploring the feasibility of building a simple application that can run on a PDA/phone and emulate a HID (Human Interface Device) over its bluetooth interface (or, USB). In this way, a nearby PC could recognize it as a keyboard or mouse instantly..."
Our current Spotlight is Media Streams Player Release 1.0.0: The Media Streams Player Project has announced the release of Version 1.0.0: "Aalhamdulillah! Most probably this is going to be the very first release of a complete cross-platform media player which is written in the Java Programming Language. Media Streams Player is entirely written in the Java Programming Language using the Java Media Framework (JMF) API. This cross-platform media player can play Video & Audio files of most of the popular media file formats on different popular Hardware & OS platforms. This application is currently under development. But this demo version which is ready to be released is a stable version of the application. End users of the application can use the Windows version of the media player just downloading & installing the Windows executable of Media Streams Player. They can find it at the Home Page of the project located at the given URL."
Our Feature Articles include Jeff Lowery's new article A Finite State Machine Supporting Concurrent States, which demonstrates how Java enums and EnumSets can be used as a basis to define and validate application states and state transitions. We're also featuring Jeff Friesen's article Introducing Custom Paints to JavaFX, which shows how you can leverage undocumented JavaFX capabilities to support custom paints in JavaFX Version 1.2.
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
