<p>Our design has one jvm that is a jboss/webapp (read/write) that is used to maintain the data via hibernate (using jpa) to the db. The model has 10-15 persistent classes with 3-5 levels of depth in the relationships.</p>

<p>We then have a separate jvm that is the server using this data.  As it is running continuously we just have one long db session (read only).  </p>

<p>There is currently no intra-jvm cache involved - so we manually signal one jvm from the other.</p>

<p>Now when the webapp changes some data, it signals the server to reload the changed data.  What we have found is that we need to tell hibernate to purge the data and then reload it.  Just doing a fetch/merge with the db does not do the job - mainly in respect of the objects several layers down the hierarchy.  </p>

<p>Any thoughts on whether there is anything fundamentally wrong with this design or if anyone is doing this and has had better luck with working with hibernate on the reloads.</p>

<p>Thanks,
Chris</p>

Chris, I'm a little confused about your circumstances. If I understand correctly, you have a both a web app (read/write) a standalone application (read-only?) using Hibernate to access a shared database. The changes you make with the web app aren't visible to the standalone app. Is that right?
If so, have you considered using a different second-level cache implementation? I'm wondering if you might be able to use a clustered cache that is shared by both the web application and the standalone application. I believe that SwarmCache, which is integrated with Hibernate, will allow this, but I haven't tried it myself.
In general, though, you should know that the contents of a given cache will never be aware of activity by another application (that's why I suggest having both apps share a cache). Good luck!