Re: Would the community be interested in these features?

Leo,

Thanks for the reply. My mistake on the which list to sent to.
Anyway. I agree that the last two features are not in keeping
with how ozone works and that optional flags would be most
fitting, assuming that folks are OK with the dirty read
integrity problems.

For nested transactions, I could make it an option. Not much
code was changed. The one behavoiral change is that if a
thread already has a transaction associated with it, the next
tx.begin() will be nested and so on and so forth. For my
project nested begin(s), rollback(s), and commit(s), with
ozone interface architecture, fits quite nicely.

- Tom

---- Original message ----
>Date: Mon, 26 Apr 2004 11:08:25 +0200
>From: Leo Mekenkamp <[email protected]>  
>Subject: Re: [Ozone-users] Would the community be interested
in these features?  
>To: [email protected]
>Cc: [email protected]
>
>On Mon, 2004-04-26 at 02:18, [email protected] wrote:
>> Folks,
>> 
>> Would the ozone community be interested in the following 
>> features (still being tested):
>
>This thread would be more on its place on the developers
list, but I'll
>reply anyway ;-)
>
>All comments IMHO...
>
>>    Major feature:
>>     - Nested Transactions
>
>Nested external transactions would be an obvious plus, even
for an
>anti-external transaction zealot like me. Since this changes
the API and
>thus could break current working programs, this would have to
be an
>optional feature. Do you have a new constructor with a
'boolean nested'
>parameter?
>
>>    Minor feature:
>>     - Dirty reads (changes also increase read performance).
>
>What exactely do you mean with dirty reads? If you mean that a
>write-locked object (lock by tx A) can be read-locked by another
>transaction (tx B), where tx B would see the 'previous
incarnation' or
>'rolled-back version' of that object, then I would have to
object (pun
>intended), since this leads to data integrity problems and
hard to trace
>logic errors.
>
>>    Whatever feature:
>>     - Explicit transactions throw an exception indicating that
>>       the transaction would block.
>>       Implicit transactions still block (in keeping with the
>>       current behavior).
>
>Could be helpful in some exotic situations. Again, this would
have to be
>optional, since it changes the API. A 'boolean
throwExceptionOnBlock'
>parameter on a new constructor?
>
>Cheers,
>Leo
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: The Robotic Monkeys at
ThinkGeek
>For a limited time only, get FREE Ground shipping on all
orders of $35
>or more. Hurry up and shop folks, this offer expires April 30th!
>http://www.thinkgeek.com/freeshipping/?cpg=12297
>_______________________________________________
>Ozone-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/ozone-users


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297