RE: framework question -- JAVA400-L

Joe,

> But not the database.  Only the program will go casters up.  When that
> happens, you fix it.  If it happens more than a couple of times, you
> find a new programmer.  There are reasons for getting rid of stupid
> programmers as opposed to trying to use commitment control as a bad code
> filter... see below.
...or the O/S.  I'm not slagging off Java here - I think Java is the best
thing to come to the iSeries in years - but we had a perfectly working
website and other background Java pgms running under V5R1.  When we
upgraded to V5R2 we've had a whole host of not readily detectable problems
(mostly not readily detectable because they require two website users to
submit transactions within a fraction of a second of each other - which
nobody ever tested after the O/S upgrade because it had always worked fine
and we had no reason to believe it would break).  Also many JDBC queries
which uses to take seconds now take 100x as long.  Commitment control
wouldn't have helped since they aren't those type of problems, it isn't
that the programs fall over in mid-transactions, sometimes they can't start
a transaction in the first place.  Just wanted to make the comment that
sometimes no matter how wonderful programmers you have, there are always
O/S problems and thousands of lines of O/S code which are completely out of
your control.

> > Corrupting that database is easy
> Not if you have any skills whatsoever as a programmer.
> And exactly how would the state get inconsistent short of programmer
> error?  And if there is a programmer error, how does commitment control
> fix that?  This is why you fire programmers who don't program properly.
> If this same bad programmer simply forgets to write the record or writes
> bad data, then commitment control buys you nothing.  In fact, it's much
> more likely that this is what will happen as opposed to an abend.
Doesn't necessarily have to be programmer error - our core system is all
Synon-generated cobol.  Some of the transactions this performs are
nightmarishly complicated and can easily take 20 seconds if the server is
loaded down with jobs running at the time.   We have the kind of
application-coded CC you mentioned before - we write a record to a 'lock'
table to say that nobody else is allowed to touch that set of records while
the transaction is in progress.  But even though we're stopping other
processes messing up the records we're working on, still anything else
could happen during this 20 seconds, job ending abnormally, subsystem
coming down, power failure, and so on.  And it does happen, and we do get
partially committed transactions because of it, and we do spend days trying
to figure out what went wrong afterwards.  True database CC is really the
only thing which helps in these kinds of situations.

Regards,

Nigel.




********************************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee; access to this
email by anyone else is unauthorised.

If you are not the intended recipient: (1) you are kindly requested
to return a copy of this message to the sender indicating that you
have received it in error, and to destroy the received copy; and (2)
any disclosure or distribution of this message, as well as any action
taken or omitted to be taken in reliance on its content, is prohibited
and may be unlawful.
********************************************************************************