Can we conform in memory via in memory only query?

Question

Can we conform in memory via in memory only query?
In other words, if I do in memory query only, does the query result will represent changes done in the UOW so far?
I thought that was the case, but then I saw this comment in EclipseLink 1.1.3, class ReadAllQuery:
// PERF: Fixed to not query each unit of work cache (is not conforming),
// avoid hashtable and primary key indexing.
// At some point we may need to support some kind of in-memory with conforming option,
// but we do not currently allow this.

Answer 1

We want to be able to do conforming against session via uow so include state in uow, and also only against uow.
Please show us how it can be done using existing API.
Scenario 1:
We have 1000 organizations loaded in the session cache, we always cache all of them, so we know we don't need to hit the db. So we would like to do query in memory via UOW to pick-up the cases we are in the middle of a transaction modifing/creating/deleting an organization and also get the session object not yet transfered to the UOW.
Scenario 2:
I do not want to flush before each query, it is a popular query. The class queried against have many thousands objects in the session cache, also there is no garanty the objects are already loaded. I send to the db the query truncating all the columns of the select except for the primary keys columns, so using report query asking for primary key only. I then verify if the objects are present in the cache, if some are not present, I retrieve the missing objects in batch from DB using the ids. Most of the time we have 100% cache hit. Then I transfer all the objects to the UOW. Then to get modification done so far in the transaction, I query in memory only in the UOW not accessing session cache because would have to iterate thousands of objects. That sound convoluted scenario but it's actually very useful in our application to get better performance without introducing stale issue. Similar scenario is that we have some query that are repeted many times during the same UOW. We can keep trace that the query have been executed one time against the DB, so that the result is loaded in memory. But then, we still need to execute again to pick-up the change in the transaction but we don't want to pay the price of iterating the many thousands instances in the session cache, when we already know UOW has all the objects that the query needs.
Thanks for helping us to leverage query in memory, an exclusive feature of TopLink/EclipseLink.