I rewrote the notification system to precreate and cache the local tx
connection events and to avoid copying the list of cels when there is only
one listener, the most common case.

Can you provide timing info as percentages of total time to demonstrate
that the apparent inefficiencies you are pointing out are actually slowing
down the driver?

On 2002.10.18 07:29:28 -0400 Ken Richard wrote:
> Your version has the same effect. Thanks for updating the source.
>
> I have a separate question about the FBManagedConnection and the
> FBPoolingConnectionManager. The FBPoolingConnectionManager calls
> FBManagedConnection.addConnectionEventListener for every connection.
> The pooling manger needs to do this so it can detect closed connections.
>
> However - the FBManagedConnection.notify method gets called for
> transaction start, commit and rollback. In a non-managed environment
> there is a lot of unnecessary processing to support the pooled
> connections. The notify clones an ArrayList and allocated a
> ConnectionEvent object.
>
> Do you see any advantage in using a separate notify interface for closed
> connections in the FBPoolingConnectionManager? It would reduce the
> overhead of cloning the list and allocating the connection event objects
> within the notify when they are not needed.
>
> The current design is nice because everything takes the same path. A
> separate notify interface would help improve performance for the "simple
> tests" that are often posted to this thread.
>
> My stats for this call are: 1 delete, 2000 insets, 1 select in
> manual-commit mode - but I committed after every transaction anyway.
> 4007 calls to notify which allocated 16K blocks for a total of 362K of
> memory.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>