Jerry Huang apps and developing apps

DbMoto is a light-weight to medium change data capture product in my opinion. It basically sync data from one database to another, to keep 2 database identical, even target and source are not the same kind of database (from DB2 to SQL for example).

One of the strengths of DbMoto is that you can write your own script in a replication, so that it could satisfy some complicated business needs. In my case, we used VB.NET as the scripting language. Recently we found some error about deadlock in the log. Originally we thought the problem was from SQL database, but we couldn't find any log entry in SQL server. We fired a ticket for vendor support. Later on they told us to use SyncLock on the TargetConnection object. So I change the script to use Monitor (better than SyncLock) instead. The code goes like:

[code language=VB.NET]

 Try
        System.Threading.Monitor.Enter(TargetConnection)
        cmd = TargetConnection.CreateCommand
        ...
  Catch e As Exception
        ...

  Finally
        System.Threading.Monitor.Exit(TargetConnection)
  End Try
[/code]

From this accident, I feel this should be a minor problem in the architecture of DbMoto, that's how the title came into my mind. In short, the object provided by Dbmoto is not thread-safe. From the point of view of framework design, when writing something will be used in multi-threads environment, it's better to make sure the objects that explosing to consumer are thread-safe. Rather than leaving the problem to sub-classes, why not just handle them internally?