Re: triggers and locking

[Jim McBeath <jimmc@xxxxxxxxxx>]

On Fri, Mar 08, 2002 at 06:45:01PM -0500, Tobias Downer wrote:
> Date: Fri, 08 Mar 2002 18:45:01 -0500
> From: Tobias Downer <toby@mckoi.com>
> To: mckoidb@mckoi.com
> Subject: Re: triggers and locking

> The only nice aspect of the current design is that with only a single
> JDBC connection, you are still able to push queries through the engine
> concurrently.  If you forced all queries to be exclusive within a
> transaction you would not be able to do this.  However, there really
> isn't much of an overhead associated with constructing and maintaining
> multiple JDBC Connections anyway.

If you can make multiple logical connection using the same physical
connection (i.e. multiple Connection objects using the same Socket), that
would be good.  Otherwise, if each JDBC Connection requires a separate
Socket, that could be an important issue for an application that wants to
have a lot of threads accessing the database.  Sockets can be a limiting
resource for a database with lots of clients, and are relatively expensive
to set up and tear down.

> So really, most of the LockingMechanism table locking functionality
> could be removed and it would probably result in no performance
> degradation for most real-world applications, and nothing will break by
> changing it.  Most real world applications have a single thread talking
> to a Connection instance anyway.
> 
> I'm thinking why not do away with table read/write locks
> altogether because I can see them being a further nuisance down the road
> with stored procedures.

I agree.  I think the improvement in simplicity from removing table locks
is probably worth the performance hit, which presumably would be small
in most cases.

-Jim