On 08 Jan 2003 16:43:11 -0200, Felipe Schnack wrote:
> I'm quite worried with the amount of synch'd code in our jdbc driver
>code, we all know this is a very costly operation in Java.
> As far as I could see from the sources, the sole objective of these
>calls are to avoid two processes accessing the same shared StringBuffer
>we use. The strangest thing, IMHO, is that every time we use this
>buffer, we are calling setLength(0) or, in plain english, resetting this
>buffer. Is just me the paranoid or this isn't helping performance at
>all? As I understand java, object creating is a very cheap operation
>these days (in the old days it was slow), but synch'ing is VERY
>costly...
There's no reason to fear about synchronisation since Hotspot anymore. The
lock, as only one process is building it, is definitely less work
than the work the garbage collector has to do in a mark-sweep cycle to
get rid of Stringbuffer over Stringbuffer (which would occur otherwise).
That said, as the syncing is upon a Stringbuffer for EACH statement, and
the statement class threaded use is discouraged anyway, we will probably
never see code really running into this.
As many many string operations are needed throughout the driver, the use
of a sync'ed stringbuffer whenever bigger string operations are made
is very wise and good style. Kudos here to the developer who made this...
The only drawback is, for the developers, that they have to be a bit
cautious with the use of it, not to produce deadlocks; but that's
rather easy, as each and every statement has it's own and the statement
class itself isn't that big.
just my 0.02¬...
sincerely,
Patric Bechtel
IPCON Informationssysteme