Hibernate version: 2.1.6

Mapping documents: None

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using: Oracle 9i

Debug level Hibernate log excerpt:


I am researching Hibernate as a solution for a possible financial search and index application. The proposed solution will allow users to find
related trades inside a database per day. There are some 100,000
trades in the corporate investment trading database.

How Hibernate handle the case of database being updated behind the JVM's back?

If I am using Hibernate to persist POJOs and there is a legacy process that interrogates the database, which is also shared with Hibernate,
and change the database using say SQL*NET or otherwise, then can
Hibernate merge the information on the next t.commit() call?

<pre>
// 1
Configuration cfg = new Configuration()
.addClass(Product.class);
SessionFactory sf = cfg.buildSessionFactory();

// 2
Trade tradeObject = fromSomewhere( sf );

// 3. Open Session
Session sess = sf.openSession();

// MEANWHILE: LEGACY External application changes
// the database table tuple that tradeObject is reflected!


// 4. Save Product and close Session
Transaction t = sess.beginTransaction();
// TradeObject is now stale even before the transaction.
// Is the solution to reread tradeObject from DB inside trx?!
sess.save( tradeObject );
t.commit();
sess.close();
System.out.println(p);
</pre>

Hibernate does not provide a cache solution of its own. Rather it delegates the cache to a provider. My question is there a good provider implementation that works very well with 25% hit ratio. In other word if all 25000 of the 100000 trades where loaded into JVM from the database, what is the community's experience of performance? What are the pitfalls I should be aware of?

MTIA

http://jroller.com/page/peter_pilgrim

It only actually matters at the point of commit(), so this looks like a versioning question more than a caching one. You can add exceptions handling if the db version is newer than the local session copy. Online docs have some information on how to integrate external applications, and a blog entry has some ideas too (http://blog.hibernate.org/cgi-bin/blosx ... 004/06/19/).

you can do this by "reflreshing" the object, but you must know when exactly

But as decairn said, this is most a versionning problem.

About cache: second level cache never knows if an extermal (batch, other app, trigger) is updating (or has updated) datas.

Online docs. Where in the wiki or faq?

Are you talking about Hibernate exceptions if the optimistic locking flag is enabled?

Yes the caching is not important at the moment. I can investigate how Hibernate caching POJO against database as secondary priority. In the proposed application where we have 100000 trades and say we have a cache size of 10000, will Hibernate alway hit the database and get the most relevant entries?

Say some trader wants to see all USD (US dollar) or Euro trades, obvious more than 10000 items will be retrieved in this dumb scenario. The cache provider will explode and either says "I cannot do it" or says "I gonna play real cool" and expand the JVM heap size to bring say 27543 Euro tuples? But in order to do this, I assume that Hibernate hits the database with the query.

If Hibernate is using the cache, let say it has 3168 Euro trades before the query went through. Will Hibernate go to the database and get latest version of the 3168 Euro trades or will it just return what has been LRU cached already?

In the use-case we want to give the trader the most up-to-date view of the trade data so s/he can make the best deals.

I hope you understand why I postulating these scenarios. I want to know if an ORM solution can perform them efficiently as well just be elegant solution to Java persistence.

Caveat Emptor on alternative:

1. We can build a traditional JDBC tier and always be sure we are hitting the database (dumb and stupid in 2004)
2. Turn off or disable the cache in the persistence layer (dumb even in the last century)

TIA

When you say "refresh" the object. You mean to reload the POJO or find and retrieve it, n'est pas?


Transaction t = sess.beginTransaction();
// TradeObject is now stale even before the transaction.

// Refresh persistence object
tradeObject = reloadTradeFromSomewhere( session );

// Work it
doWhateverMan( tradeObject );

sess.save( tradeObject );
t.commit();
sess.close();
System.out.println(p);


TIA

I don't really understand your question.

By nature, if I cache data from the database in my application, it is not going to know about changes made by other applications. There are three possible solutions:

(1) don't cache
(2) configure a sufficiently short cache expiry
(2) implement some kind of notification mechanism so that your application is informed when the other app changes data, and can force a cache refresh.

(1) don't cache

Can you tell Hibernate not to use cache? I thought a cache provider
was required to use it.

(2) Configure a sufficient short cache expiry.

I think that would defeat to the aim of caching.

(3) Implement notification

This would very much a traditionally solution. Flush the cache in order to
remove stale out-of-date data. Or perhaps write a service interface or
MDB or even a web service that allows the application to refresh or
passes the information. I agree with that.


I think my problem is that I do not understand enough of how Hibernate
works technically. One needs to know how the ORM is doing its thing.
How does it persist data back and forth with caching in mind?

There three ideas

A) I would like to design the proposed new system to use a ORM solution
such as Hibernate instead of writing JDBC.

B) The system must support dynamic query (or rather complex where
clause) that the user has control of it via a wizard.

C) Our financial system is like most other systems. We do not have 100%
exclusive access to a database. There are external
legacy systems (and manually administrators) who may go behind
the ORM back and modify the database as trading needs.

D) The system must be able to cope with real time data and feeds
from external agents outside the business. It must demonstrate that trade data as they view on the screen (web user) is clear, concise and accurate.

Now forget about the possible latency between the web, business logic and data persistence tiers.

I need to be able to see if Hibernate fits the business requirements.

Given that Hibernate is the starting block for the EJB 3.0 specification you can see why I researching this question: What is the best way to synchronise information inside the database server and Java tiers with an ORM solution?

Can Hibernate actually me as a developer / architect?
Or should I start recomending writing EJB 2 or straight-ass JDBC calls?

I think it makes sense if you start from scratch with the first chapters of Hibernate in Action.

yeah, actually, that *is* the best way

I'd say don't cache. And learn some more about Hibernate.

Well thanks all the same for your pointers ....


Have a very nice day ;-C

Why do I have to buy a book to give our clients a straight answer?

At the moment we are looking at various ORM solutions including Hibernate.
We are asking the same questions with Oracle TopLink and other tools
before we starting designing and building a proposed solution. Should
we buy books for TopLink and Kodo JDO before we get starting as
well as yours?

Surely you can understand why we are reluctant to commit to tool
whether open source or proprietary unless we know that "it does
what it says it does on the tin" or we can use this tool in our
mission critical project.

BTW: Thanks for listening ...

Peter P

You have to do nothing, it's your choice if you want to learn or not. We don't sell software, like the other two companies you quoted. Please don't use them to tell us what we should do or not do.

We are offering a $20 book that will answer your caching questions (those that haven't already been answered here), as well as the other more basic questions you brought up. If you want to invest more time, and not money (I think $20 are quite reasonable for the amount of knowledge that is in the package), you will find answers in the reference documentation. It just doesn't offer any handholding and you will have to read and try it.

You are using an open source software. Open source software, by definition, "always does what it says on the tin". None of the issues you brought up are a real problem, we have seen similar questions many times. We are also experienced when it comes to answering those questions, and the reason why you get these answers is: we know that it would take many hours on the forum to tell you what you will have to know to make an educated decision.

As this is a free gig and we don't offer this kind of personal service here, you'll have to use the documentation, read a book, or contact us for our professional services if you need them. You have all options, but don't be angry because someone tries to show you the way.

Oh, and if you like marketing talk (which I'm sure you get from the vendors you quoted), you can contact us and we will tell you what you like to hear, at least if you make it clear that you like to do this up-front.

The fundamental thing is:

We are not salespeople trying to sell you something. If you choose our solution, we don't make any money at all off of you.

So we can't afford the time to hold your hand. (On the other hand, we also can't be bothered lying to you.) Different economics. Consider our point of view, I know its unconventional.

If you go with our solution, you will save you and your clients many thousands of dollars, all for the $40 cost of a book, the only book on the market that explains ORM technology.

If you want a very broad answer to your question: Hibernate has a similar cache architecture to Kodo, and slightly different (more sophisticated, IMO) than what TopLink has at this time.

It is a two level cache, where the second level is granular. Which means that while, yes, Hibernate always does caching, the first level cache is not a cause of data-staleness, due to its limited scope. The second-level cache is optional, and can be enabled only for the particular data for which it is appropriate.

But I cant really try and fully explain "2+1 level cache architecture, granular cache, cache concurency strategy, etc, etc ,etc" in a forum post. (Perhaps someone else has time.)

There are about 2 chapters of the book which deal with all these concepts in great depth, in a way which simply can't be covered here.

heh, sorry, christian said it all :)