ECO中的对象乐观锁定(Optimistic Locking)

多客户端ECO技术的对象操作乐观锁定(Optimistic Locking)
    ECO中的对象乐观锁定设置位于ECO类的design-time属性中，用于解决多个客户端同时进行修改而带来操作冲突，比如有个ECO类Person，里面有两个属性Firstname:string和Lastname:string，如果有两个客户端读取同一个Person记录后，其中一个客户端修改了此实例的Firstname并更新了数据库(Ecospace.UpdateDatabase)，而另一个客户端对这个类的Firstname作了修改和数据库更新，于是就产生了该类实现在数据库中的值的覆盖和锁定的问题。

    ECO对于类的锁定作了下面的选择:
1. Off设定，相当于直接实现update Person set Firstname='newvalue' where BOLD_ID=8，另一个客户端的修改将被冲刷掉；

2. Default设定，则这个类的乐观锁定取决于它的父类的乐观锁设定；

3. ModifiedMembers，这个设定是先判断已修改的属性在数据库中是否已改变(如：select a.BOLD_ID, a.BOLD_TYPE, a.Firstname from Person a where a.BOLD_ID=8) 取回的值与第一次读取值不同的话则产生"Optimistic locking failed for 1 objects"的Borland.Eco.Internal.BoldSystem.EBoldOperationFailedForObjectList 的异常报告。

4. AllMembers设定，操作与ModifiedMembers相类似，只是在ECO内部查看已修改值的方式是查询并返回所有的属性值(select * ...)

5. Timestamp设定，启用这个值需要在ECOspace中把PersistenceMapper组件的SqlDatabaseConfig.UseTimestamp值修改为True，然后在Ecospace中点击右键，使用Evolve Database补充生成一个叫ECO_TIMESTAMP的数据表，这个表只有一个BOLD_TIME_STAMP整数字段，一旦我们修改Person类的值之后要写入数据库中，ECO会先执行： Update ECO_TIMESTAMP set BOLD_TIME_STAMP=BOLD_TIME_STAMP+1，然后返回这个stamp值，然后再执行对象的数据库更新Update Person set Firstname='newvalue' where bold_id=8 ，此时ECO会自动执行一个小事务，先判断当前数据库中的stamp值是否和刚才加1并取回的值相同（确认此间没有他人更新数据），则数据更新成功，否则返回Optimistic locking failed for 1 objects. 也是一个EBoldOperationFailedForObjectList的异常。使用Timestamp方式的ECO类单独使用一个stamp数据，不会和其它类的stamp识别冲突，我们可以把这个stamp值看成是数据更新事务的ID号。

    此类锁问题同样也出现在Java服务器上面，比如Jboss等对EJB的实现，看起来Borland的ECO对于此类问题还有很多需要完善的。