[
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 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-tp22957109p23039456.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
