Comments on: Serializable != Synchronized, especially not with Oracle http://joemorrison.org/blog/2009/07/18/serializable-synchronized-especially-not-with-oracle/ How I Learned to Stop Worrying and Love Writing Software Thu, 09 Sep 2010 02:12:50 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Omri Ben Shitrit http://joemorrison.org/blog/2009/07/18/serializable-synchronized-especially-not-with-oracle/comment-page-1/#comment-8680 Omri Ben Shitrit Thu, 11 Feb 2010 14:59:25 +0000 http://joemorrison.org/blog/?p=64#comment-8680 Hi Joe, A nice link on Wikipedia thats relevant: http://en.wikipedia.org/wiki/Software_transactional_memory Omri Hi Joe,

A nice link on Wikipedia thats relevant:

http://en.wikipedia.org/wiki/Software_transactional_memory

Omri

]]> By: choy http://joemorrison.org/blog/2009/07/18/serializable-synchronized-especially-not-with-oracle/comment-page-1/#comment-5363 choy Wed, 22 Jul 2009 07:34:14 +0000 http://joemorrison.org/blog/?p=64#comment-5363 Couldn't the "send message" be included in the same transaction as the database update. if you were using Oracle AQ, I'm quite sure it would be. But assuming you're using some external system and the cost of two-phase commit (JTA, Enterprise Services) is too much, the best-effort thing Daniel suggested with the message sent after is not bad. it just has to be understood that the QoS for the message is lower than the update. Oracle approach to serializability is a nice option. not too useful for a not-so-concurrently-updated account row in only one table. But perhaps useful for account transfers when you want to avoid locking both accounts. Couldn’t the “send message” be included in the same transaction as the database update. if you were using Oracle AQ, I’m quite sure it would be.

But assuming you’re using some external system and the cost of two-phase commit (JTA, Enterprise Services) is too much, the best-effort thing Daniel suggested with the message sent after is not bad. it just has to be understood that the QoS for the message is lower than the update.

Oracle approach to serializability is a nice option. not too useful for a not-so-concurrently-updated account row in only one table. But perhaps useful for account transfers when you want to avoid locking both accounts.

]]> By: vaandu http://joemorrison.org/blog/2009/07/18/serializable-synchronized-especially-not-with-oracle/comment-page-1/#comment-5355 vaandu Tue, 21 Jul 2009 13:48:02 +0000 http://joemorrison.org/blog/?p=64#comment-5355 It is very useful, I was just seraching difference bet. the serializable and for update. Thx a lot Joe It is very useful, I was just seraching difference bet. the serializable and for update. Thx a lot Joe

]]> By: Joe http://joemorrison.org/blog/2009/07/18/serializable-synchronized-especially-not-with-oracle/comment-page-1/#comment-5337 Joe Sun, 19 Jul 2009 13:45:44 +0000 http://joemorrison.org/blog/?p=64#comment-5337 Thanks, that's a good suggestion. It works for this example - as long as the code correctly retries upon transaction failure - and in any case where you can postpone all side effects (e.g. sending the message) until after the database updates. Although that's not always possible, e.g. if the details of the database update depend on a response from the side-effecting operation. Thanks, that’s a good suggestion. It works for this example - as long as the code correctly retries upon transaction failure - and in any case where you can postpone all side effects (e.g. sending the message) until after the database updates. Although that’s not always possible, e.g. if the details of the database update depend on a response from the side-effecting operation.

]]> By: Daniel Chait http://joemorrison.org/blog/2009/07/18/serializable-synchronized-especially-not-with-oracle/comment-page-1/#comment-5332 Daniel Chait Sun, 19 Jul 2009 01:17:07 +0000 http://joemorrison.org/blog/?p=64#comment-5332 Nice post Joe. One thought - in this example, you could just send the message after you have actually withdrawn the $100 from the account. Re-ordering your steps so that the data is committed before sending the message would be the more sensible approach here anyway. Nice post Joe.

One thought - in this example, you could just send the message after you have actually withdrawn the $100 from the account. Re-ordering your steps so that the data is committed before sending the message would be the more sensible approach here anyway.

]]>