I want to stay as close as possible to the current query API So just override @Override public Query setResultTransformer(ResultTransformer transformer) { this.resultTransformer = transformer; return this; } in FullTextQueryImpl from the Query API and use the resultTransformer instance. On Oct 25, 2007, at 23:48, John Griffin wrote:

Markus Heiden wrote: Yes I have noticed O(N) performance in ActionQueue looking for work to do (or dirtyness or something) when there is a large active set of Objects in play. Don't forget that your underlying DB has to also track individual items too. Is your issue memory or O(N) performance ? I found the performance was the killer over a few 1000 objects. Break the transaction down, i.e. have a 2 stage pattern with your data, you initially create a persistable entity with a status=1 and commit batches of items in this state. Any code that picks up that persitable entity (in DAO layer) ignores any instances where state=1 (conceptually they don't really exist yet since they are non-active). Once your large transaction has finished creating all these new entites with state=1 then you run a new transaction which marks them all with state=2 (conceptually this is an active state). You can maintain your own active object list by simply holding the primary key value in a list, and this is what you walk. If your list is really huge then you may need to persist that separately too! Until you can get the business logic within the constraints of the CPU/memory resources you have for the task. At some point given a large enough working set you will need to break your problem up into smaller transactions and redesign your approach. Maybe the above pattern has a name, its a bit like a Java builder pattern but for the construction of large amounts of data in a transactional way. Maybe this pattern is no use to you and you really want the moon on a stick to happen on your 386 with 640Kb. Darryl

You need it for the post commit insert event. But we could optimize that if there is no such event. On Nov 9, 2007, at 21:21, Markus Heiden wrote:

You're missing one part, how about custom event listeners. Hibernate Search used to use those events and needed the entity instances for example. For the optimization, the JIRA issue has not been created AFAIK. On Nov 11, 2007, at 17:00, Markus Heiden wrote:

No what I am talking about is not related to the caching system. On Nov 12, 2007, at 17:31, Shawn Clowater wrote:

Hi Shawn, I experienced some time ago, that turning off the 2nd level could help getting rid of memory consumption problems, but wasn't able to track down the problem exactly. Your problem is the same problem as mine. As a solution I suggested to cut the references to the instances (application objects) in all Entity*Actions to be able to garbage collect the instances when they are no more needed by the application. The Entity*Actions would still be in ActionQueue.executions but this memory consumption should be acceptable. As a workaround turning off the query cache works for this problem too (at least if the Entity*Actions have hasAfterTransactionCompletion() == false), because the Entity*Actions aren't cached at all in ActionQueue.executions (as you already described). Markus Heiden