[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 166 - Does atomicity in assign imply variablelocking?
andrew.francis@mail.mcgill.ca wrote: Hello Danny: DJ> assignment is already atomic. yaron's proposal DJ>adds implicit locks to give programmers a concurrency DJ>crutch. YY>The easy solution would appear to be to YY>declare that assigns always execute in an implicit YY>serialzable scope but this 'easy' solution causes YY>some conceptual problems in the case that the scope YY>the assign is a member of is itself already serializable. YY>This edge case matters because of: What exactly is this solving again? What does this have to do with the initial question "does atomicity in assign imply variable locking"? I feel atomic assignment and concurrency are orthogonal issues. If it is a "concurrency crutch" that one wants, why not implement finer grained and explicit control via some form of synchronize "activity" this was my point, exactly. as far as the transaction discussion, i was referring to ACID transactions, and i agree with all of your points in relation to Long Running Transactions. I just think they're very different beasts, and that "isolation" is related to ACID, which has little or no presence in BPEL.sequence { a = b synchronize { c = d } } DJ> i mildly disagree that compensation is that related to DJ> transaction processing. Compensation is directly associated with transaction processing. More specifically transactions that cannot be treated as atomic (cannot be rolled back to their original state). The BPEL specification refers to the Molina "Sagas" paper. Another example: Satish's Issue 10 strawman rules, I believe they are related to the locking theorems in the "Isolation" chapter of Gray and Reuters "Transaction Processing." That book deals extensively with transaction processing vis-a-vis databases.the only ways that a BPEL programmer would deal with transactoins are either through a complext distributed transaction protocol,The BPEL process itself can be seen as the implementation of a complex distributed transaction protocol. I thought one of the points of BPEL was to tie otherwise stateless web services with stateful programmatic glue to create a bigger web service/automaton?i would argue, the programmer has enough knowledge to pine for mutexes. in the latter, since the transaction has either committed or been rolled back external to the BPEL process, the programmer need know nothing of it.And what about the case of when the BPEL process is the implementation of a transaction? Perhaps I am missing something? However I think you are describing trivial BPEL processes.Referring to database isolation levels, therefore, is too arcane.For curiousity's sake alone, I want to understand how scopes and compensation work (I thank Satish for being so patience in answering my questions). I also suspect that an application programmer should have some awareness of how BPEL's scopes and compensation mechanism works, if for no other reason than to write a proper compensation handler. Then there there is the issue of implementing the compensation mechanism..... Cheers, Andrew |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]