RE: EJB versus RPG/COBOL

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> 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