> Take concurrency conrol for an example. By default, SQLServer works in > optimistic concurrency control. You happily write your application not > worrying about lock conflicts until commit time. When you port such an > application to DB2, you realize you have to handle lock conflicts much > sooner (at the time when you perform "update"). You have to add some UI > to > notify the user of the possible conflict. In fact, DB2 does not even tell > you that it's waiting on a lock. It appears that the application has > simply > hung. > > In order to cancel out of this blocked situation, you have to cancel the > operation, which typically means you have to do this in a separate thread > (unpleasant task). > > Some little differences will make you spend a long time. Data type > conversions always annoying and could be time-consuming. For example, > Oracle has 'NUMBER' keyword for a numeric column, DB2 does not. You have > to > search and replace NUMBER with DECIMAL. Oracle lets you specify a > primary-key column without 'NOT NULL' keywords. DB2 does not (each PK > column must have NOT NULL).
[snip] And that's why you use CMP, cmp engine handles it... and if the app server's cmp engine is dumb then use something like MVCSoft's persistence manager which is cheap and works on many app servers. Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
