Hi,
I tried
@Test
public void testDirtyTxQuery() throws Exception {
graph.createVertexType("vTX");
final CountDownLatch latch = new CountDownLatch(1);
final AtomicBoolean shutdownFlag = new AtomicBoolean(false);
final ExecutorService executorService = Executors.newCachedThreadPool();
final Future inserter = executorService.submit(new Callable<Void>() {
@Override
public Void call() throws Exception {
OrientGraph graph = new OrientGraph(DB_URL);
latch.await();
int counter = 0;
while (!shutdownFlag.get()) {
graph.addVertex("class:vTX", "val", "val" + counter);
counter++;
graph.command(new OCommandSQL("select count(*) from VTx")).execute();
if (counter % 100 == 0)
graph.commit();
}
return null;
}
});
final Future fetcher = executorService.submit(new Callable<Void>() {
@Override
public Void call() throws Exception {
OrientGraph graph = new OrientGraph(DB_URL);
latch.await();
while (!shutdownFlag.get())
graph.command(new OCommandSQL("select count(*) from
VTx")).execute();
return null;
}
});
latch.countDown();
Thread.sleep(300000);
shutdownFlag.set(true);
inserter.get();
fetcher.get();
}
No issues.
Could you provide test case ?
On Fri, Feb 28, 2014 at 8:17 PM, Odysseas <[email protected]> wrote:
>
> I am continuing to investigate this problem to try and resolve it. It
> looks like if you do a query against the database that looks at records
> that are temporary, we get an exception.
>
> For example, while importing lots of records into the database using one
> transaction for a fixed block of records (not a single transaction for all
> N records that need to be imported but one transaction for a block M of
> records where M << N), if before the transaction is committed you do a
> query such as (select count(*) from V) then we get an exception to the read
> operation that complains about the state of the transaction being in an
> invalid state.
>
> If my analysis is correct, then this to me is either a bug or we are not
> using the API correctly. I'll ask again for suggestions on what is causing
> this.
>
> Thanks,
> Odysseas
>
> On Friday, February 28, 2014 1:16:38 PM UTC-5, Odysseas wrote:
>>
>>
>>
>> On Tuesday, February 18, 2014 8:45:27 AM UTC-5, Odysseas wrote:
>>>
>>>
>>> We are transitioning our application from 1.6.3 to 1.7-rc1 and have run
>>> into an issue when re-deploying the application. When we first deploy the
>>> application everything is working fine but if we redeploy it, it doesn't
>>> seem
>>> to be shutting down properly because during the restart we are getting
>>> the following exception:
>>>
>>> Caused by:
>>> com.orientechnologies.orient.core.exception.OSerializationException:
>>> Cannot load database's configuration. The database seems to be corrupted.
>>> at com.orientechnologies.orient.core.storage.impl.local.
>>> OStorageConfigurationSegment.load(OStorageConfigurationSegment.java:74)
>>> at com.orientechnologies.orient.core.storage.impl.local.paginated.
>>> OLocalPaginatedStorage.addDefaultClusters(OLocalPaginatedStorage.java:
>>> 1933)
>>> at com.orientechnologies.orient.core.storage.impl.local.paginated.
>>> OLocalPaginatedStorage.open(OLocalPaginatedStorage.java:191)
>>> ... 137 more
>>> Caused by: com.orientechnologies.common.concur.lock.OLockException:
>>> File '/mnt/sysnet/person-db/database.ocf' is locked by another process,
>>> maybe the database is in use by another process. Use the remote mode with a
>>> OrientDB server to allow multiple access to the same database.
>>> at com.orientechnologies.orient.core.storage.fs.OAbstractFile.
>>> lock(OAbstractFile.java:375)
>>> at com.orientechnologies.orient.core.storage.fs.OAbstractFile.
>>> openChannel(OAbstractFile.java:641)
>>> at com.orientechnologies.orient.core.storage.fs.OAbstractFile.
>>> open(OAbstractFile.java:141)
>>> at com.orientechnologies.orient.core.storage.impl.local.
>>> OSingleFileSegment.open(OSingleFileSegment.java:53)
>>> at com.orientechnologies.orient.core.storage.impl.local.
>>> OStorageConfigurationSegment.load(OStorageConfigurationSegment.java:54)
>>>
>>> During the shutdown process we close the pool first (OrientGraphFactory)
>>> and then shutdown the storage as before:
>>>
>>> final OStorage stg = Orient.instance().getStorage(
>>> entityStore.getStorageName());
>>> if (stg != null) {
>>> stg.close();
>>> }
>>>
>>> The close on the storage is performed successfully. What are we missing
>>> here? Is there a way to track who has the storage still open?
>>>
>>> Thanks,
>>> Odysseas
>>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Best regards,
Andrey Lomakin.
Orient Technologies
the Company behind OrientDB
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
