ConformResultsInUnitOfWork

(When conforming results) every query will need to be processed against the database to determine a set of candidate rows for which object are built or retrieved from the shared cache. Then each must be processed against the UnitOfWork to see:

• if new objects exist that match the criteria
• if existing objects in the candidate set have changed to no longer match the criteria
• other objects of the same type have been modified to now meet the selection criteria

Now, don't get us wrong. This is a critical piece of functionality that prevents you from having to maintain transient state on the database. Shorter more precise database transactions will help the overall performance of your DB server.

We are probably just overly cautious about people not understanding what is going on and using this to the detriment of their performance goals. If you have reasonable transaction sizes where you only register the objects being modified in the UnitOfWork this can be an excellent tool to simplify your development. forum:277344

Session properties can be used as an alternative to a conforming query -- see FindingNewObjects.

Example:

        ExpressionBuilder user = new ExpressionBuilder();
        Expression exp = user.get("name").equal(name);
        
        // find new objects in this TX
        ReadObjectQuery q = new ReadObjectQuery(User.class, exp);
        q.conformResultsInUnitOfWork();
        
        return (User) uow.executeQuery(q);

Note that conformResultsInUnitOfWork implies checkCacheThenDatabase -- they are both convenience methods for setCacheUsage.

See Also

FindingNewObjects, forum:280729, forum:240825, forum:206806

The UnitOfWorkPrimer has a good section about conforming queries.