[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Error pulling back records with FetchType=LAZY
|
The only other thing I can think of is it could be some kind of invalidation
issue, are you setting a cache invalidation timeout?
I would recommend you log a bug for the issue, and include all of the
information you have gathered. If you have an Oracle support contract
please also contact Oracle technical support.
As a workaround, either disable the shared cache for the class
(@Cache(shared=false)), or use the cache isolation setting that seems to be
working, it should have no adverse side-effects.
The only issue with the large OneToMany was performance.
James Sutherland wrote:
>
> The error does not make sense in this situation. In EclipseLink when
> cloning object from the shared cache, cache locks are first obtained on
> the objects (and any EAGER relationships). If you had many threads trying
> to access the same set of objects and the same time and starting with
> different objects in the cycle, then you could potentially get this error.
> But you have only a single thread accessing these objects, so this makes
> little sense.
>
> In your first post you mentioned a different error than this one. Do any
> errors occurs before you get this error? They could be the root cause.
>
>>> ECLIPSELINK-02004: A signal was attempted before wait() on
>>> ConcurrencyManager. This normally means that an attempt was made to
>>> {0}commit or rollback a transaction before it was started, or to
>>> rollback a transaction twice.
>
> Could you also try making the manager relationship from Employee LAZY,
> does this fix the issue?
>
> A workaround may also to be to set,
> session.getLogin().setCacheTransactionIsolation(DatabaseLogin.CONCURRENT_READ_WRITE);
>
> using a SessionCustomizer.
>
> Also in general it is normally not a good idea to map a 1-m for a
> collections that has 60,000 objects. Normally it is better to query for
> such a result when required.
>
>
>
> Kevin Lester wrote:
>>
>> James, thanks for the response. Answers to your questions below:
>>
>> Also include what is occurring when the error occurs, you seem to have
>> multiple threads inserting objects, is that correct, how many threads, do
>> they each use a different EntityManager?
>> I start two threads that each populate the Manager with NUM_EMPLOYEES
>> Employees (this set to 59,999 in the test code, but will be over 100,000
>> in our app). Once both threads complete, I start two ManagerUpdater
>> threads that each persist the new manager objects. The ManagerUpdater
>> does the following (full code can be found at the end of the
>> EclipseLinkLazyTester class):
>> manager = updateManager(manager);
>> logger.info("Manager " + manager.getName() + " has " +
>> manager.getEmployees().size() + " employees");
>> The updateManager method saves the manager, and then returns a fresh copy
>> of the manager. The logger.info method prints out the number of
>> employees that were persisted for the manager, and this is where the
>> error occurs. The employees are LAZY loaded from the manager, so when we
>> call getEmployees().size(), the employees are loaded, and this is where
>> we get the error for some reason. The actual persistence of the Manager
>> and Employee objects succeeds, and I see the proper values in the DB; it
>> just errors out when the employees are lazy loaded from the fresh manager
>> object for some reason.
>>
>> Each ManagerUpdater thread uses its own EntityManager.
>>
>> James Sutherland wrote:
>>> Could you include the full exception for the stack trace
>> Full stack trace below:
>> 10:15:14,137 INFO [EclipseLinkLazyTester] persistanceUnitName:
>> testPersistenceUnit
>> 10:15:15,485 INFO [EclipseLinkLazyTester] Thread for updating manager
>> Homer starting
>> 10:15:15,486 INFO [EclipseLinkLazyTester] Thread for updating manager
>> Carl starting
>> #Build files from manager in same session = 59999
>> 10:16:36,264 ERROR [EclipseLinkLazyTester] Error occurred updating the
>> manager
>> java.util.concurrent.ExecutionException: Exception [EclipseLink-2007]
>> (Eclipse Persistence Services - 1.1.0.r3634):
>> org.eclipse.persistence.exceptions.ConcurrencyException
>> Exception Description: Max number of attempts to lock object:
>> Emp_Carl-27839 exceded. Failed to clone the object.
>> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>> at EclipseLinkLazyTester.insertDBRecords(EclipseLinkLazyTester.java:79)
>> at EclipseLinkLazyTester.main(EclipseLinkLazyTester.java:92)
>> Caused by: Exception [EclipseLink-2007] (Eclipse Persistence Services -
>> 1.1.0.r3634): org.eclipse.persistence.exceptions.ConcurrencyException
>> Exception Description: Max number of attempts to lock object:
>> Emp_Carl-27839 exceded. Failed to clone the object.
>> at
>> org.eclipse.persistence.exceptions.ConcurrencyException.maxTriesLockOnCloneExceded(ConcurrencyException.java:60)
>> at
>> org.eclipse.persistence.internal.helper.WriteLockManager.acquireLocksForClone(WriteLockManager.java:97)
>> at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:873)
>> at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:811)
>> at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor.getAndCloneCacheKeyFromParent(UnitOfWorkIdentityMapAccessor.java:171)
>> at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor.getFromIdentityMap(UnitOfWorkIdentityMapAccessor.java:110)
>> at
>> org.eclipse.persistence.internal.sessions.IdentityMapAccessor.getFromIdentityMap(IdentityMapAccessor.java:327)
>> at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3708)
>> at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3668)
>> at
>> org.eclipse.persistence.mappings.CollectionMapping.buildElementClone(CollectionMapping.java:207)
>> at
>> org.eclipse.persistence.mappings.CollectionMapping.buildCloneForPartObject(CollectionMapping.java:164)
>> at
>> org.eclipse.persistence.internal.indirection.UnitOfWorkQueryValueHolder.buildCloneFor(UnitOfWorkQueryValueHolder.java:51)
>> at
>> org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:162)
>> at
>> org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:230)
>> at
>> org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
>> at
>> org.eclipse.persistence.indirection.IndirectSet.buildDelegate(IndirectSet.java:192)
>> at
>> org.eclipse.persistence.indirection.IndirectSet.getDelegate(IndirectSet.java:343)
>> at
>> org.eclipse.persistence.indirection.IndirectSet.size(IndirectSet.java:500)
>> at
>> EclipseLinkLazyTester$ManagerUpdater.call(EclipseLinkLazyTester.java:304)
>> at
>> EclipseLinkLazyTester$ManagerUpdater.call(EclipseLinkLazyTester.java:1)
>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> Also the code for EmpCreator, or ExecutorService,
>> ExecutorCompletionService.
>> The code for the EmpCreator is at the end of the EclipseLinkLazyTester
>> class. The ExecutorService and the ExecutorCompletionService are built-in
>> Java classes that are part of the java.util.concurrent package.
>>
>> Just to reiterate my findings they are as follows:
>> 1). This issue can only be reproduced if the employees have a FetchType
>> of LAZY. Changing them to EAGER makes the test project work.
>> 2). Reducing the size of NUM_EMPLOYEES can also make the test project
>> work. Through trial and error I found that if I set the NUM_EMPLOYEES to
>> < 50,000 or so, everything works. If I set it above 50,000 it fails.
>> The actual threshold of records that cause it to fail is not constant,
>> but it seems to always work if set the number beneath 50,000 or so. Not
>> sure if this is significant, but I found it interesting if nothing else.
>>
>> Is this simply a configuration issue where I need to increase some value
>> to allow for lazy loading of my large data set without causing errors?
>> The fact that it works with ~< 50,000 employee records per manager
>> implies that this might just be a configuration issue but I'm not sure
>> what to tweak.
>>
>> Thanks
>> Kevin
>>
>
>
-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/Error-pulling-back-records-with-FetchType%3DLAZY-tp22957109p23059596.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
