Jerry Huang apps and developing apps

The previous blog I wrote last night is something about DbMoto. Today I found that my feeling is a bit more than that, so I list out the summary how I feel after using this product.

1. It’s basically a good tool for syncalizing data from DB2 to SQL, in my case. Easy to setup and use comparing with some jumbo products. It provides a nice GUI tool to setup and manage replications.
2. Not very good for real time change data capture, currently we set the interval to 30 minutes, i.e. data will sync from DB2 to SQL every 30 minutes. There was a time we set to 5 minute but it seems there were some problems. I am not sure about the detail (I'm not in the AS400 team), what I heard fromt my colleague is that the receiver in AS400 caused the CPU overran.
3. The product and the company have a long history and the market share is growing. The support is ok; so far they solved all problems we hit, as I can remember.
4. I believe the engine is base on .Net framework 2.0, so it needs to run on a Windows server. This is ok for us but some people insist the performance is better if a product is base on non-Microsoft server.
5. Very good extensibility, we can write our own script into the replication. We are using VB.NET as script language, but I guess it also supports other .NET languages. The script will be compiled to .NET binary code so the efficiency will be better than those dynamically compile.
6. Scripting is good but also brings the biggest problem – there is no way to debug the script in development. What we are doing now, is to write log for debugging. For development, ideally we hope the dbmoto engine somehow can call into Visual Studio so that we may set breakpoint, watch the value of local variables, etc. Due to this, we avoid to put something too complicated in the scripts.

Overall, I will say dbmoto is a light-weight to medium change data capture engine, to keep 2 different databases identical. If your requirement is not about some sort of comprehensive ETL solution, just to sync data from one place to another, DbMoto should be a good tool for that. However, it might not suit for you if require extremely low latency (i.e real time) syncalization. Hmmm, but real-time is a big challenge for all products.

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?