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.

David Morris

>>> joepluta@xxxxxxxxxxxxxxxxx 3/12/2004 11:27:31 AM >>>
> From: David Morris
> 
> The only real difference is
> that I change an object model in memory and Hibernate flushes those
> changes on a commit.

Ah, now we're getting into some interesting areas.

Personally, I don't care about SQL input.  Tweaking inquiries is
always
a game and I don't much care for it.  But caching requests and
flushing
changes on commit, that can be significant.  On a typical transaction
run, do you only commit after the entire batch, or do you commit on a
transaction by transaction basis?

Caching is a time-honored way of reducing disk latency, but it has
certain drawbacks, one of which is the architectural overhead.  If
you're using entity beans as a way of encapsulating a caching
methodology, that's to my mind an exceptionally astute use of the
technology.  The concern is over lost data in an extraordinary
exception
situation, but I imagine you've got that addressed.

Since caching is in effect bringing a portion of the file into memory,
it would be nice to compare that against the same application where
the
affected files are pinned into RAM.

Joe