RE: EJB versus RPG/COBOL

> Joe,
> 
> Hibernate stores objects in memory with a changed flag. Changed items
> are flushed on commit but it can be forced with a flush. Most of the
> time you make all your changes in memory and then commit at the end.
> Hibernate can be configured to prevent updates based on stale data.
> There is a default order for changes that works 99% of the time but
> occasionally you will need to flush. Most significant for performance
is
> caching and lazy initialization, which you have to use carefully to
> avoid issues like stale data and initialized lazy relationships.

Ha! I knew it.  Write caching.

I'm not sure how often you flush, but write caching is perhaps the most
powerful performance enhancement you can make to a system.  It is also
easily the most dangerous, especially if your application allows things
like key changes; if a key change is not committed, logical views can be
distorted and depending on the complexity of the system that can be
fatal.

I wrote an entire database object system back in a previous life which
supported things like shadow writes and dirty reads, and all I can say
is that it takes a LOT of careful programming to keep everything
working.  It gets especially difficult when a database field is shared
among multiple objects.  And of course, if your system crashes without a
commit, you lose everything.  Performance vs. risk is always a classic
tradeoff.

The problem is that the crash usually occurs under heavy production
load, like when you run out of memory.

But it's good to hear someone making it work.  Personally, I've been
looking at Hibernate and it seemed like it had some potential.  The fact
that it uses write caching, but that the caching seems to have a
reasonable levfel of user control, makes it worthwhile.

Joe