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.
