Search code examples
javahibernatecachingsecond-level-cache

Hibernate database integrity with multiple java applications


We have 2 java web apps both are read/write and 3 standalone java read/write applications (one loads questions via email, one processes an xml feed, one sends email to subscribers) all use hibernate and share a common code base.

The problem we have recently come across is that questions loaded via email sometimes overwrite questions created in one of the web apps. Note, these are separate questions which should have separate id's. We originally thought this to be a caching issue. We've tried turning off the second level cache, but this doesn't make a difference.

<property name="hibernate.transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
<property name="hibernate.current_session_context_class">thread</property>
<property name="hibernate.cache.use_second_level_cache">false</property>

Question:

@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "id", unique = true, nullable = false)
@DocumentId
public Integer getId() {
    return this.id;
}

We're using MySQL btw.

CREATE TABLE  `question` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  ...
  PRIMARY KEY (`id`),
  ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8

We are not explicitly opening and closing sessions, but rather let hibernate manage them via Util.getSessionFactory().getCurrentSession().

We'd rather not setup a clustered 2nd level cache at this stage as this creates another layer of complexity and we're more than happy with the level of performance we get from the app as a whole.

So does implementing a open-session-in-view pattern in the web apps and manually managing the sessions in the standalone apps sound like it would fix this?

Or any other suggestions/ideas please?


Solution

  • Turns out this problem wasn't related to Hibernate at all.

    One of the database tables on the staging server was filled with old data that should have been cleaned up. This initially gave the appearance of id's being overwritten, but further investigation proved otherwise!

    Once we removed the dodgy data, all was well.