Quoting Rickard Öberg <[email protected]>:

On 2010-02-18 03.07, Stanislav Muhametsin wrote:
I ran to this same issue myself a couple days ago. Well, my issue is
regarding strictly to creating of entities. I'm not sure about deleting,
as it seems that it gets stuck at

41188 [main] INFO org.openrdf.sail.nativerdf.NativeStore - Waiting for
active connections to close before shutting down...

for indefinite amount of time whenever I shut down - maybe I should have
waited even longer. Actually came to think about it, this might be
exactly that - the other thread is doing deleting, which is taking huge
amount of time, and when shutdown is initated from another thread, it
waits till that gets completed - apparently a very long time.

The problem manifested itself already with couple thousand entities or
so. And that wasn't even a fairly large usecase in our project. Of
course I might need to re-work on architecture a bit and maybe turn
those entities into value-composites or something.

One important question: are you trying to create thousands of entities in one UnitOfWork? How many? And delete?

I would *strongly* suggest that you don't create/delete more than say a thousand entities per UnitOfWork, due to memory usage.

Also, are you using native or memory repository?

/Rickard

I was creating I'd say around thousand entities in one uow, before I divided it to do same work in many smaller uow's.

I managed to make the profiler work again (somewhat), it's still unstable as hell. So far it seems that even when doing 200 entities test (new uow, creating 200 entities, completing uow, new uow, deleting 200 entities, completing uow), the execution time for test is around 7sec or so. And around 40sec when profiling. That's terribly slow (IMO), and I'm no longer sure why - 50% of execution time are lost "somewhere", and profiler doesn't know where. And I'm unable to make that getExclusiveLock() to show up in results anymore (with 200 entities). Maybe it is confused because of Qi4j's class generation. This needs further research...


_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to