Transaction theory

[SkipDever]

I am still trying to get my brain around EntityListIterator and the need to
have a transaction in place when one is created.

There is this code in GenericDelegator.findListIteratorByCondition()

        if (!TransactionUtil.isTransactionInPlace()) {
            //throw new GenericEntityException("ERROR: Cannot do a find that
returns an EntityListIterator with no transaction in place. Wrap this call
in a transaction.");

            //throwing an exception is a little harsh for now, just display
a really big error message since we want to get all of these fixed...
            Exception newE = new Exception("Stack Trace");
            Debug.logError(newE, "ERROR: Cannot do a find that returns an
EntityListIterator with no transaction in place. Wrap this call in a
transaction.", module);
        }

What I am wondering is why this code is required if you are cursor forward
and read-only.  Also, why would the read-only/forward iter.next() want to be
inside a transaction.

I have written JTA transaction code currently used by 25% of the fortune 500
processing thousands of transactions per second and never put these kinds of
queries inside a transaction.  If anyone can help me understand the need, I
would be grateful.

Skip
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
9:34 AM

[Jacopo Cappellato-3]

On Apr 24, 2008, at 5:30 AM, skip@thedevers wrote:

> I am still trying to get my brain around EntityListIterator and the  
> need to
> have a transaction in place when one is created.
>
> There is this code in GenericDelegator.findListIteratorByCondition()
>
>        if (!TransactionUtil.isTransactionInPlace()) {
>            //throw new GenericEntityException("ERROR: Cannot do a  
> find that
> returns an EntityListIterator with no transaction in place. Wrap  
> this call
> in a transaction.");
>
>            //throwing an exception is a little harsh for now, just  
> display
> a really big error message since we want to get all of these fixed...
>            Exception newE = new Exception("Stack Trace");
>            Debug.logError(newE, "ERROR: Cannot do a find that  
> returns an
> EntityListIterator with no transaction in place. Wrap this call in a
> transaction.", module);
>        }
>
> What I am wondering is why this code is required if you are cursor  
> forward
> and read-only.  Also, why would the read-only/forward iter.next()  
> want to be
> inside a transaction.

I think that David has recently explained this very well; you may try  
to reread one of his recent emails on this subject.
However, part of the reason is in the way (you have many options) you  
want to read data: you may google on this complex and interest subject  
using the keywords "isolation level".
Not all the jdbc driver and db have support for all the isolation  
levels; in Ofbiz the isolation level is setup in the entityengine.xml  
file:
isolation-level=None, ReadCommitted, ReadCommitted, Serializable,  
RepeatableRead

Jacopo

>
>
> I have written JTA transaction code currently used by 25% of the  
> fortune 500
> processing thousands of transactions per second and never put these  
> kinds of
> queries inside a transaction.  If anyone can help me understand the  
> need, I
> would be grateful.
>
> Skip
> Internal Virus Database is out-of-date.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date:  
> 4/16/2008
> 9:34 AM
>

[SkipDever]

Jacopo

This isolation-level is the piece of information I was missing.  In all my
previous code (previous to Ofbiz), I had transactions only around the writes
except in a few select cases where the data read had to match the data
written which was not often.

I think I now feel comfortable commenting out that  "if
(!TransactionUtil.isTransactionInPlace()" code, setting my services to
use-transaction="false", and doing my own transaction management.

Thanks a ton.

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Wednesday, April 23, 2008 10:25 PM
To: [hidden email]
Subject: Re: Transaction theory



On Apr 24, 2008, at 5:30 AM, skip@thedevers wrote:

> I am still trying to get my brain around EntityListIterator and the
> need to
> have a transaction in place when one is created.
>
> There is this code in GenericDelegator.findListIteratorByCondition()
>
>        if (!TransactionUtil.isTransactionInPlace()) {
>            //throw new GenericEntityException("ERROR: Cannot do a
> find that
> returns an EntityListIterator with no transaction in place. Wrap
> this call
> in a transaction.");
>
>            //throwing an exception is a little harsh for now, just
> display
> a really big error message since we want to get all of these fixed...
>            Exception newE = new Exception("Stack Trace");
>            Debug.logError(newE, "ERROR: Cannot do a find that
> returns an
> EntityListIterator with no transaction in place. Wrap this call in a
> transaction.", module);
>        }
>
> What I am wondering is why this code is required if you are cursor
> forward
> and read-only.  Also, why would the read-only/forward iter.next()
> want to be
> inside a transaction.

I think that David has recently explained this very well; you may try
to reread one of his recent emails on this subject.
However, part of the reason is in the way (you have many options) you
want to read data: you may google on this complex and interest subject
using the keywords "isolation level".
Not all the jdbc driver and db have support for all the isolation
levels; in Ofbiz the isolation level is setup in the entityengine.xml
file:
isolation-level=None, ReadCommitted, ReadCommitted, Serializable,
RepeatableRead

Jacopo

>
>
> I have written JTA transaction code currently used by 25% of the
> fortune 500
> processing thousands of transactions per second and never put these
> kinds of
> queries inside a transaction.  If anyone can help me understand the
> need, I
> would be grateful.
>
> Skip
> Internal Virus Database is out-of-date.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date:
> 4/16/2008
> 9:34 AM
>

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
9:34 AM

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
9:34 AM