Jonathan Huang

There is very limited documentation. You have to buy their expert guides to get everything you need.

Hibernate isn't a framework or follow one. It's a service.

Spring MVC is a good MVC Framework which hibernate works very well in.

I found that WTP 0.7 for Eclipse was using older lib files then what Hibernate Tools was using causing classpath issues.

That was my reasons for Hibernate Tools not working. There could be others though.

Sometimes if the object's values changed in the DB hibernate needs to refresh the Session level cache or it might use old values. This is because if the item is in the session, it'll pull it from the session instead of the DB. Try a session.refresh on your object.

http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html

I don't think I was very accurate in my description of the problem but hopefully these will remedy my ignorance.

http://forum.hibernate.org/viewtopic.php?t=927602&highlight=timestamp+date+sql

http://forum.hibernate.org/viewtopic.php?t=925275&highlight=timestamp+date+sql

You also have to remember that if you have a Timestamp in the DB and take it out, Hibernate takes it as a date, you lose precision... Or am I backwards?

Anywho, to keep your precision you need to write a custom type to type cast properly.

There are some good dicusions of this at the official forums.

2nd level Cache

The alternatives are what you can dream up.

Session per transaction
Session per app
Session per HTTPSession

Session for every 2 transactions....

etc. . .

It all depends on how many users may potentially be using the system, how well you want to be able to grow your system, etc, that will ultimately decide which way to go with your session.

The reason to use the session in view pattern is so you can lazy load objects in the view. It is easy to write a filter that opens and closes the thread bound session so you don't have to take care of it programatically.

Also, the Spring framework comes with some handy features such as transaction AOP point cuts and a OpenSessionInViewFilter already made for you. It removes all the boiler plate code for you, and you can focus on your business logic.

As to not mapping collections . . . Sounds interesting. Let me know how that goes. And if you don't have any collections you could use the session per transaction strategy. It works very well for simple schemas.

Look at the CaveatEmptor example hibernate provides. You can also check out a plugin for Eclipse called HibernateSync. I wouldn't recommend using it, but just to look at the code it generates. Gives you insight on other posibilities.

good luck

I started by reading the entire Hibernate 3 docs. Then doing the Hibernate in Action demo. Then just testing things out and writing code/mappings.

Then reading the offical and these forums whenever possible. Someone elses problem could always be my own.

Most problems you get you can figure out from the docs or reading forums. The more in depth stuff you are going to have to go through source code and their Jira issues.

There are lots of best practices you can learn from the Hibernate Caveat Emptor example and the Hibernate Wiki pages are nice.

The reason might be because everytime you call HibernateSessionFactory it is instantiating a new SessionFactory.... which is bad. But I haven't seen all your code so I could be wrong.

For examples of a DAO patterns used with Hibernate, you can check out the CaveatEmptor example, HibernateSync, and after you have an understanding of those, you might like to check out Spring's IOC container.

CaveatEmptor can be found at: http://caveatemptor.hibernate.org/
Just do a google for HibernateSync

Could you post the calling code and stacktrace? Off hand I don't see anything wrong with your code/mappings.

Well, at least I know I am not going crazy.

I've been working through the second level cache functionality, returning the CacheTypes and playing around with them. Im trying to find an association between the Role Name, and the Entity Name so I can evict them myself progamatically. The best I can do so far is evict the entire region, and not the individual associated values.

I'll let you know how it goes.

Im looping through the cache stats (in a .jsp page):
This is how I know what exactly is being evicted and what is not.

org.hibernate.stat.Statistics stats = sf.getStatistics(); String[] regionNames = stats.getSecondLevelCacheRegionNames(); for(int i = 0; i < regionNames.length; i++) { Map cacheEntries = stats.getSecondLevelCacheStatistics(regionNames[i]).getEntries(); out.println("<b>Cache Region:</b> " + regionNames[i] + "<BR>"); out.println("<b>Cache Stats: </b>" + stats.getSecondLevelCacheStatistics(regionNames[i]).toString() + "<BR>"); Object[] keys = cacheEntries.keySet().toArray(); for(int j = 0; j < cacheEntries.size(); j++) { out.println("<b>Cached Item: </b>" + cacheEntries.get(keys[j]) + "<BR>"); } out.println("<hr>"); }

And just so we're both clear, The Parent.Child collection is being evicted from the Second Level Cache.

The Child objects that Parent.Child points to are NOT being evicted. That's where im having issues.
[ August 18, 2006: Message edited by: Jonathan Huang ]

So each different DS will need a different .cfg.xml file.

in each one you can do <class-cache> and <collection-cache> tags. Just set the region="someRegion" different in each one so that even though they're in the same JVM, they'll be looking things up from different locations.

Check out the Hib3 documentation for more details.

Sorry, let me try to explain myself a little bit better. This is essentailly my expectations:

A1 has a collection B1
A2 has a Collection B2

B1 contains B_B1, B_B2, B_B3
B2 contains B_B5

B_B1 Points to Q1, B_B2->Q2 and B_B3->Q3.
B_B2->Q10
If I evict A1 (and it's collections), shouldn't A1, B1, and Q1, Q2, Q3 all be Evicted from the cache. So, not the entire cache region, but just the associated values.

So for a more concrete example (all set to be cachable):

Parent.id=1 that has a collection of
child.id=1, child.id=2, child.id=3.

Parent.id=2 that has a collection of
child.id=2, child.id=4, child.id.5

In hibernate's cache stats, I will see 3 regions:
Parent, Parent.Child, and Child.

In the above example, Parent.id=1 and Parent.id=2 share Child.id=2.

There are 2 things which I don't understand going on:

1) If you set Cascade=evict on the Parent.Child collection in the mapping file, why does:
SessionFactory.evict(Parent.id=1), not evict Parent.Child where Parent.id=1

2) If you do SessionFactory.evictCollection(Parent.child, id=parent.id=1) why does:
Parent.Child.id=1, parent.Child.id=2, and Parent.Child.id=3 (the parent's collection) is evicted from the cache. But why isn't Child.id=1, Child.id=2, and Child.id=3 NOT evicted.

Still left in the cache SHOULD be:
Parent.id=2
Parent.Child.id=4, Parent.Child.id=5
Child.id=4, Child.id=5

It is my understanding that if cascade=evict (or as the documentation states, should be set to "all" or "all-delete-orphan"), on the parent's collections, the associated collections will be evicted. On top of that, since the associated collections, are really pointers to another entity in the cache, those should be evicted as well. Not the entire cache region, but just the ones associated.

Hope that helps explain myself better...
[ August 18, 2006: Message edited by: Jonathan Huang ]