RE: Java Style Question -- JAVA400-L

For me, it went something like this:  A Connection object and a Statement
object are tightly coupled to each other.  The statement 'belongs to a
connection'.  They clearly have references to each other so that they can
stay in synch (close on connection should close any statements left open
under it for example).  So we started going down the path of just letting
the statement get at the internals of the connection for whatever it might
need.

But later, we start seeing heavily threaded applications, applications
sharing transactions (via JTA support sitting on top of JDBC), etc.  So we
synchronize everything in connection and synchronized everything in
statement to stop two threads from messing up a single object, but the
problem that remained was that threads doing stuff to the statement are
'free' to modify the connection because they didn't call a method on the
connection, they just changed what they wanted to.  This caused some
inconsistancies that were very hard to track down.

The 'big hammer' approach isn't good, because we don't want everything
locked to the connection or only one statement could do work at a time...
so we had to go through the process of breaking apart the places where
these objects could manipulate each other directly so that we could
synchronize them correctly.  Its a pretty hard thing to do after the fact.
Combined with the fact that nearly all of our time (performance) is spend
doing 'real' work, allowing the objects to have direct access to each other
was a mistake in the first place...

I probably didn't explain that very well.  The real issues were, at times,
the result of very complex interactions.  And, of course, they were rarely
easy to recreate so you could analyze them effectively (you're always in
trouble when you turn on debug and the problem goes away).

The lesson I learned (at least sort of learned... I'm a long ways from
perfect about it yet) is that you need to write code from the start like
you expect a lot of people to use it or risk having a lot of nasty issues
on your hands trying to make it work for them later.  Setter/getter methods
are a prime example of a good practice to protect yourself (there are
dozens of others).

Richard D. Dettinger
iSeries Java Data Access Team

Democracy's enemies have always underestimated the courage of the American
people.
It was true at Concord Bridge.  It was true at Pearl Harbor.  And it was
true today.

         Rochester Post-Bulletin
         Tuesday September 11, 2001


|---------+---------------------------->
|         |           "David Morris"   |
|         |           <David.Morris@plu|
|         |           mcreek.com>      |
|         |           Sent by:         |
|         |           java400-l-admin@m|
|         |           idrange.com      |
|         |                            |
|         |                            |
|         |           04/09/2002 12:23 |
|         |           PM               |
|         |           Please respond to|
|         |           java400-l        |
|         |                            |
|---------+---------------------------->
  
>----------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                               |
  |       To:       <java400-l@midrange.com>                                    
                                               |
  |       cc:                                                                   
                                               |
  |       Subject:  RE: Java Style Question                                     
                                               |
  |                                                                             
                                               |
  |                                                                             
                                               |
  
>----------------------------------------------------------------------------------------------------------------------------|



Richard,

I agree that performance is a non-issue and getters/setters
offer an opportunity to add your own hooks into a class.
I am wondering why a getter or setter for a class variable
changes the multi-threading issue. Most multi-threading issues
I have run into are fixed by passing them as parameters
and avoiding either direct access or access via getter/setter.

David Morris

>>> cujo@us.ibm.com 04/08/02 10:22PM >>>

...2) Later you start multi-threading something that you never worried
about
threading issues for initiallly.  You start making various objects
safe
from the outside users and that is pretty easy, but you have all kinds
of
thread safety holes where two objects clobber each other's internal
state
from two threads that are allowed to execute at the same time...

Richard D. Dettinger

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.