Tricky thing in EclipseLink/TopLink

Recently, I got problem when I used a DB adapter in SOA suite to insert a record into DB with a sequence. I always got the follow exception.
Exception Description: The sequence named [AVS_REQUEST_SEQ] is setup incorrectly. Its increment does not match its pre-allocation size.


Searched by google and found somebody wrote the follow.
Use 100 as a start value will resolve the problem: by default the start value is 1, when Eclipselink attempts to use the first allocated sequence value it's negative 1 - 100 + 1, that causes the exception.
(Reference: http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg03461.html)

The above setting solved the issue, but I got a sequence number is 52 instead of 1. I keep to search and found another answer.
You must change the DBAdapter properties in WebLogic deployments console, make the preallocationSize same as the one used for the sequence.
<config-property name="sequencePreallocationSize" value="1"/>


I checked my connection setting in DBAdapter, the value is really 50 and that is why I got a sequence from 52 (101-50+1).

The follow step is the way to change the preI've found it. It is in the dbAdapter connection pool's configuration of sequencePreallocationSize.


In the Weblogic's console:
1) Deployments->dbAdapter
2) Configuration's Tab
3) Click on
4) Click on your ConnectionPoolFactory
5) Properties' Tab
6) Change 'sequencePreallocationSize' property's value to 1. Press ENTER to actually change it.
7) Click Save button.
8) Go to Deployments
9) Check dbAdapter and click Update
10) Click Finish

This is really a tricky thing.

Hibernate Cache

Hibernate is a well-know persistence framework in the  Java world, it comes with a wonderful API to ease application communication with the database. Caching is a mechanism that stores data so that future requests for that data can be served faster. It’s a good point for performance when there are a lot of requests for the same stuff . 


Hibernate comes with 3 caching mechanisms to resolve this issue.

First Level Cache

A hibernate session is a unit of work that’s corresponding to a DB transaction. When doing operations on entities, these latters are not stored immediately in DB but wait until the session commits. The hibernate session is hence representing the first level cache and it’s enabled by default.

Second Level Cache

A hibernate SessionFactory aims to create sessions, initializes JDBC connections and pool them. The second level cache lives in the SessionFactory level so all session can share it. This is why it’s called a process scoped cache.

The second level cache is not enabled by default. One has to configure the cache strategy for hibernate entities and the cache provider that will be a third party caching API like EHCache.

Query Cache

This is related to second level cache and is used for caching queries with parameters. It has to be configured like the second level cache.

To know if the application is hitting the cache, you can configure it in the session factory configuration file and begin your unit tests to get an idea of performance.