Hi,


I've been studying and reading plenty of forum discussions and articles, read - of course - Hibernate in Action, but yet, I failed to find a proper way to design Hibernate into my application.

Furthermore, any approach we took by now brought us eventually to ugly race conditions and Hibernate exceptions. Therefore, I am posting my questions here, ready to be shouted at that "it is trivial! How come you haven't come up with that simple simple solution? You are misusing Hibernate" etc...

I'm designing a server. The server receives streams of data items simultaneously, and builds trees of POJOs to represent the received data. The streams (of unknown lengths or durations: seconds to months) do not share POJOs. Other important facts: streams may get quiet for a while (say, a couple of hours), then get back to life again. We do not expect more than tens of streams open at the same time. POJOs may be updated some time after created (in response to arriving data). Within the tree of POJOs, nodes point up (to the parent) and contain children.

Here is what we do Hibernate-wise in this section of the server: each stream is assigned a Hibernate session + transaction. Each POJO, after created is saveOrUpdated on this session. A scheduler is set to run a job every x seconds, to commit all the transactions and open new ones for the streams' sessions. When a stream ends, the corresponding transaction is committed and the session is closed. Calls to saveOrUpdate are synchronized with commits. All transactions are committed by the same thread.

So far so good. But here comes the interesting part: a certain type of a POJO created within a stream context as described, is thrown into a queue. This queue receives POJOs from all streams, i.e. - POJOs attached to various Hibernate sessions.

The queued POJOs (let's call them Events) are consumed by a dedicated thread. That thread constructs a grouping POJO (let's call it an Incident) and attaches Events to it. In other words, one Incident has many Events. Each Event has one Incident. The two POJOs (Event, Incident) maintain this one-to-many relationship programmatically.

I can't update the Event from the Incident-creating thread, because the Event POJO is connected to the stream's session. I can, however, have the Incident-creating thread open a hibernate session per Incident, find the Event's ID and session.get it from the database (maybe after waiting until it arrives at the database, since stream items are committed every x seconds). However, I keep getting inconsistent exceptions and behaviors when doing that. It is important to understand that Incidents group Events from different streams, and a stream contributes to many Incidents. I can commit an Incident session when the incident is finished (Incidents have reasonable durations).

If I made myself clear, and I didn't lose you by being too verbose, can you please suggest how can I allow the stream session to create an Event, then the Incident session to update it?


You help will be inbelievably life saving.

Thanks in advance,


Noam Rotem.

"You help will be inbelievably life saving" is the Neanderthal form of saying "Your help will be unbelievably life saving".

Here is the full Neanderthal phrase: "Me ask. You help. Will be inbelievably life saving"...


Your help will be unbelievably life saving.

Thanks,


Noam.

Could you elaborate on that? Could you provide stack traces?

Your problem is far from simple with multithreading and session/transaction that are closed asynchroneously. So it's pretty hard to give smart advices from the distance.

When I first read your post, I thought I would try to attack the problem using evict on the Event objects in the session they're coming from and lock in the session with the Incident. Meanwhile I doubt that this would be better than what you've already tried.

The central issue seems to be that you cannot do anything with an Event as long as you're not sure the session/transaction it is saved in is actually terminated. You would need some clever synchronisation mechanism.

I'm wondering if you could not simplify/redesign your application so that you get rid of the whole problem. Again, it's very difficult to say anything knowing so little about your application and without knowledge which alternative you have already tried. For example: why can't the Event objects be saved in the Incident thread?


I really hope that no life depends on the solution to this problem...

Erik