XPQuery Intransaction problem

Hi Noxe,

This behavior is correct. In InTransaction mode XPO removes some clauses from the query that may be affected by uncommitted changes and processes returned objects on the client side.

Thanks,
Michael.

hmm - scary - this query loads have of my database - where it should return 2 or 3 records - thats a huge performance impact! How else should i load my objects and also take into account my local ones?

Hi Noxe,

I am afraid we cannot improve the performance in an InTransaction mode because uncommitted data may unpredictably affect the result. In addition, we should also check whether objects have been changed in the database. I regret to inform you that there is no workaround. If you know which uncommitted objects should be included in the (BeforeTransaction) result list or removed from it, process them separately.

Thanks,
Michael.

Hi Michael,

i still dont understand, that when i request "where r.OrderLineItem != null && r.OrderLineItem.Oid == lineitem.Oid" from the database, XPO simply ignores my where condition and queries the database without where...? can you clarify why this is done?

Hi Noxe,

It is rather difficult to determine which objects actually need to be retrieved. For example, we have class Person that has a reference property pointing to class Address. We have loaded some Address object and changed the City property to "London". Now we wish to retrieve Persons with Address.City='London'. If we do not remove criteria from the query, it will return only Persons that meet the criterion in the database, but miss Persons that refer to a modified Address object. If we do not load Persons referring to that Address object before modifying it, we cannot even add them manually to the result collection.

In previous versions we simply remove filter criteria from the query in InTransaction mode. In version 10.1 we improved the InTransaction mode logic to detect certain situations that can be optimized. Your scenario seems to be more complicated. We do not consider the current behavior as a bug because the result is correct. If you provide us with a small sample project demonstrating your scenario, we will research whether or not it is possible to optimize queries. You are welcome to post a suggestion about this improvement.

Thanks,
Michael.

Hi Michael,

today i faced the same problem - even worser. It seems that some of the latest hotfixes changed again something in the Transaction loader, because our app stopped working because of OutOfMemory Exception because of InTransaction queries:

            collection.AddRange(new XPCollection(
                PersistentCriteriaEvaluationBehavior.InTransaction,
                _session,
                _session.GetClassInfo(lineitem),
                operand == lineitem.Oid & LineItemBase.Fields.ObjectType.Oid == objectType.Oid).Cast<PriceLineItem>());

See the query above - i search for an LineItem object where the operand equals the objects OID - and is of a specifiy type. XPO removes the query operand == lineitem.Oid - and queries the whole database, the result is a outofmemory exception.

How can i avoid that???

I did some tests now:

11.1.8 - code works
11.1.8.11280 - code works
11.1.8.11294 - whole table is loaded !?

Hi Noxe,

Thank you for your report. We have reviewed the most recent changes of our code but cannot find a possible cause for this behavior. Would you please provide us with a small sample project reproducing this issue?

Thanks,
Michael.

Hi Michael,

i also checked your source and between 11280 and 11294 you did some changes in the intransactionloader which is actually breaking the functionality. its annoying that i always have to proove there is a problem - preparing such an example will again need much time, dont counting the time i already spent today in debugging the problem...

Why do you publish an hotfix where nothing was changed? I downloaded the hotfix and compared the sources, no change was made in this regard....?