Object-relational mapping (in the JPA compliant sense) is so ubiquitous nowadays in the Java development scene, that we rarely question ourselves if we really need it, and if not using it may be a better option.
In my experience, some systems benefit from using JPA technology (most systems actually), but some do not, in fact I think some systems become unnecessarily complicated and bigger because of it.
Sometimes you just don’t want or need the complexity of a fancy distributed transaction manager or complicated RPCs to coordinate a concurrent job amongst a farm of servers.
Here is a very simple and efficient way to achieve a lock/release type of concurrency control in a farm-like architecture using nothing but a few SQL sentences and your relational database.
In our first installment we reviewed the front-end part of developing a paginated list using AJAX and Java. Now we will dive into the back-end of our pagination mechanism.
Do you really need to have a database table with all existing countries? What’s the benefit? Apart from adding one more database query to each page hit and an array to each users context while loading that form…
Think it over, every software component’s goal must be, first of all, to satisfy the users needs as fast and as reliably as possible. Considering the “fast” part, you must always evaluate if it’s really necessary to store this kind of info in a database table, and penalize the applications overall performance by adding another database query, recordset run through and a whole bunch of new objects in an array in request or session context.