Giter Site home page Giter Site logo

managedesent's Introduction

ESENT Managed Interop

ManagedEsent provides managed access to esent.dll, the embeddable database engine native to Windows.

The Microsoft.Isam.Esent.Interop namespace in EsentInterop.dll provides managed access to the basic ESENT API. Use this for applications that want access to the full ESENT feature set.

The PersistentDictionary class in EsentCollections.dll provides a persistent, generic dictionary for .NET, with LINQ support. A PersistentDictionary is backed by an ESENT database and can be used to replace a standard Dictionary, HashTable, or SortedList. Use it when you want extremely simple, reliable and fast data persistence.

esedb provides both dbm and shelve modules built on top of ESENT IronPython users.

managedesent's People

Contributors

2bitsalute avatar damirainullin avatar denis12484 avatar michaelthorp avatar microsoft-github-policy-service[bot] avatar robertmuehsig avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

managedesent's Issues

PersistentDictionary - Exception in .NET Core 2 application

I get the following exception when I try to create an instance of a PersistentDictionary in a .NET Core 2 console application.

"Type 'System.RuntimeType' in Assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' is not marked as serializable."

The database is created though.

Consider migrating away from Vista/Windows2003/Windows7 namespaces

Now that Windows 7 is no longer getting Security Updates, and there are many different versions of Windows 10, it may make sense to take steps to get rid of the Vista/Windows2003/Windows7 namespaces.

  • Copy all of the grbits/APIs from Vista/Windows2003/Windows7 to the main namespace, helping with discoverability.
  • Remove many of the compatibility tests.
  • In a future release, remove the Windows2003/Vista/Windows7 namespaces. Obviously that would be a breaking change, so could be done later (or not at all?).
  • Leave Windows8/Windows81 alone for now, since they are still supported OS's.

Can't run on Debian 10 (possibly other Linux instances as well) due to kernel32.dll native call to get ProcessId

Unhandled exception. System.TypeInitializationException: The type initializer for 'HomeProject.Program' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Database.Isam.Config.DatabaseConfig' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'kernel32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libkernel32.dll: cannot open shared object file: No such file or directory at Microsoft.Database.Isam.Win32.NativeMethods.GetCurrentProcessId() at Microsoft.Database.Isam.Config.DatabaseConfig..cctor() --- End of inner exception stack trace --- at Microsoft.Database.Isam.Config.DatabaseConfig..ctor() at Microsoft.Isam.Esent.Collections.Generic.PersistentDictionaryDefaultConfig.GetDefaultDatabaseConfig() at Microsoft.Isam.Esent.Collections.Generic.PersistentDictionary2..ctor(String directory, IConfigSet customConfig, IEnumerable1 dictionary) at Microsoft.Isam.Esent.Collections.Generic.PersistentDictionary2..ctor(String directory)
at Logic.Caching.PersistedCache1..ctor(String persistedCachePath, Func2 serialize, Func2 deserialize) in <... not your area anymore>

I tracked it down to DatabaseConfig and yes, it is using Native call to get ProcessId to have a mutex name. Can you please replace native call with something more cross-platform? Thanks in advance.

Building details (run on windows): dotnet publish -r debian10-x64 --self-contained
dotnet version: 3.1.403
target: net core app 3.1

May be it's dotnet publish fault (it didn't get something right from platform-dependent nuget?), I'm just really lazy to install SDK on Debian so I expected it to work.

New NuGet Package for v.1.9.5

On Nuget there is still only the old version 1.9.4 available.
Can you please add a package for v.1.9.5 and include the Esent.Collections.dll.
By the way the version number or the DLLs is 1.9.4.1 and not 1.9.5, why?
Maybe you could make use of multi-targeting by adding a ".NET Standard 2.0" target to nuget.

However what is really needed is a .NET Core 3.0 compatible version.
It is not that easy as System.RuntimeType is not serializable and therefore the BinaryFormatter in Api.SerializeObjectToColumn in Microsoft.Isam.Esent.Interop fails. The issue #9 was closed without a reason.

Assembly signing

There was assembly signing issue before v2.0.3 version (#45), but the same issue is again in v2.0.4.

Increasing limit of an existing long value column

Is there a way to increase the cbMax for a long binary column? I'm pretty sure I can get what I need by adding a new column and combine the two at run time, but it's obviously not as clean.
Related, is there any cost to just specifying the limit to the physical max for this new column? I'd like to avoid coming back to this issue in the future if it's decided that the new limit isn't large enough again. Certainly I would not get any safety checks if I unintentionally try to store a value that exceeds my intended max, but it's fine for me to take that risk on myself.

Exception flowing out of PersistentDictionary`2.Dispose(Boolean) prevents handle close and subsequent re-open?

Hi,

We have a test case where clustered storage is transiently failing, and then we try and close the persistent dictionary so we can re-open it once cluster storage is healed. The close throws an exception after (apparently) doing a portion of the close work, and never (apparently) gets to closing handles (maybe GC will eventually close them, in indeterminate time?). Then, trying to reopen the database fails because the database handles from the previous instance are still open.

We see the exception at close time looking like:

<EsentInstanceUnavailableException> This instance cannot be used because it encountered a fatal errorHResult: (0x80131500)
   PersistentDictionaryCursorCache`2.Dispose()
   PersistentDictionary`2.Dispose(Boolean)

And then our subsequent re-open fails with:

<EsentSystemPathInUseException> System path already used by another database instanceHResult: (0x80131500)
   Api.JetInit2(JET_INSTANCE&, InitGrbit)
   Instance.Init(InitGrbit)
   PersistentDictionary`2..ctor(String, IConfigSet, IEnumerable`1)
   PersistentDictionary`2..ctor(String, IConfigSet)

It seems the problem is here:

try
{
    this.disposeLock.EnterWriteLock();
    writeLocked = true;

    if (this.alreadyDisposed)
    {
        return;
    }

    this.cursors.Dispose();
    this.database.Dispose();
    this.instance.Dispose();
}
finally

If this.cursors.Dispose() throws (I am guessing that from the CursorCache in the stack above?), then the following lines never run, leaving handles open (until GC?)???

Shouldn't we be guaranteed that handles are immediately closed after dispose regardless of whether writes can be flushed to disk or not? So that the database can be reopened?

It seems our only option with the current implementation is to exit the whole process and have cluster manager restart it, which we'd prefer not to do.

Is there something we might be doing wrong here to be able to close and reopen our database when storage fails transiently, without exiting our process?

Thanks for any insights!

-- Rich ([email protected])

Isam: IndexFlags does not have IndexTuples

If you add

IndexTuples = 4096 

to IndexFlags.cs, (and CreateIndexGrbit) and then

if (indexDefinition.Flags & IndexFlags.IndexTuples) == IndexFlags.IndexTuples)
{
grbit = grbit | (CreateIndexGrbit)(int)DmcIsamCreateIndexGrBit.IndexTuples;
}

in DatabaseCommon::GrbitFromIndexDefinition then we will be able to use Tuple Indexes from this code.

Concurrent write causes huge file size

Hello,

In my application I need to (concurrently) access as quick as possible to byte arrays stored on disk.
I have a multi threaded method where each thread preform read write access to its own byte array, one array per thread. The method is executed in a loop; at each iteration I need to read the previous state and save the next one. The read operation is performed at the begin of the method to initialize it and the write is at the end, to store the iteration state. The length of each byte array may change from one iteration to the other.

To satisfy these specifications I use an esent database where each byte array is stored in a different table having one row and one column.

Everything works well on my development machine, with relatively low degree of parallelism and fast disk (SSD), but, as often happens, the problem arisen in the production environment, a virtualized machine with 12 cores and possibly slower, but still SSD, disk.

The size of the .edb file in the production machine reached ~50GB after few iterations, while in the dev environment it never exceeded the 15GB.

I also reproduced the problem on my dev environment writing a program that just write byte arrays of random length, filled with random data thus maximizing the concurrent write accesses.
I temporarily solved the problem with a Lock statement around the write operation, but I'm looking for a better solution (e.g. using a number of databases equal to the degree of parallelism).

The following is a snippet of my test application with full parallel and locked versions:

string parallel = "parallel.csv";
using (StreamWriter outfile = new StreamWriter(parallel)){
    for (int i = 0; i < iterations; i++){
        Parallel.For(0, tables, j => {
            byte[] buffer;
            Random r = rr[j]; 
            long size = r.Next(minBytes, maxBytes);
            buffer = new byte[size];
            r.NextBytes(buffer);
            esentDb.Write(j, buffer); //save the data on disk
        });
        outfile.WriteLine("{0}",  new FileInfo(parallel).Length);
    }
}
string locked = "locked.csv";
using (StreamWriter outfile = new StreamWriter(locked))
{
    for (int i = 0; i < iterations; i++)
    {
        Parallel.For(0, tables, j => {
            byte[] buffer;
            Random r = rr[j];
            long size = r.Next(minBytes, maxBytes);
            buffer = new byte[size];
            r.NextBytes(buffer);
            lock (lockObject){
                esentDb.Write(j, buffer); //save the data on disk
            }
        });
        outfile.WriteLine("{0}", new FileInfo(locked).Length);
    }
}

with this example I optained a .edb file size of ~1.5GB in thhe full parallel case and ~300MB in the locked one, both after 100 iterations

KeyNotFoundException / EsentKeyDuplicateException when using certain keys

Hi all,

I have noticed that some specific keys will cause KeyNotFoundException / EsentKeyDuplicateException exceptions when trying to use the dictionary.

For example, here is a LinqPad script:

void Main()
{
	var databasePath = "C:\\Test";
	var databasePageSize = 16384;
	var databaseConfig = new DatabaseConfig
	{
		DatabasePageSize = databasePageSize
	};

	var persistentDictionary = new PersistentDictionary<string, string>(
		directory: databasePath,
		customConfig: databaseConfig);

	var key1base64 = "woQhOsKbf8OZwpnCkncFw6NtccOiwpwGwrTDqMOcKBjDln7DqMKYAkfCv2oBw5J+w6s4IiV6w4vDrxDCoMK6NsOowqbDp03CtBfCjkHCqwPCiQXCrsKiUQN8wpLDmid1MmTCgTnDgHbCi8Opw7jDi8KIXcKfwpZCwrDCtMKSwqfDm8OAJ3piMnPCgynDh3J9w4XCk8OBwrZBZRTDs8KhAlfCszgAwqgOCw5Sw4jDvzJLwrQLw6kfBkzDsmIhwoZNw4LDicOdw6AASsKfwp4Gw5lodEJhwolleBt1wqp+wpNHDMKqV0YOwqfCrsKgNSzDqj3DnjArDggoYCxyS8KXwqfCvXzDp3pHwqzDm8OPL8KCw5E1wqgDwpHDt1c4M0dXI8KrNEwMbcKCHWbDlcOBE8KwwonCkcK/NFnCiFEbDVxfw7ZlBMKWacOUORhQUMKZw5HCsy46P1jCssOIwqwPIcO4egA3I8OfwqrDtTwVTsOUVcKnaMOswrTCksKbwqjDg1/Dr8OADAYfScO5aUTCr0/DlW3CicKWMcKxWm5aFMKDwoLDnsOYwpLDlmzDvTYRZ13CmMKLPysdw4Bhw7zDksOQwp/ChMKAOsOfVcKDw6BBOmhLaz0uLcKMcsKMaw7CnsOod8OUw75WBcKUwpkMXkHCssOjWVhYw7cWelbDjyzDtU0fAsO9w680w65vZ8OCAMKbCGXDocO/fUvCpy0JCcK5WcOUw5Qze3bDsMK3w47CvMKCwofDnlMIwqRlHsOvw5nDr8Oiwr1Pw7MVFsO9CijDvsOrQ2bCqCgaAHPDuXcLMsOfwobDngLCq3TCp0EPGi/DiXcWwoRAZV/DssKtwqXCvcKWRHjCq8OfwolkwqrDtWLDpMKvw57DiRUTa8KIY8Omw67DkBPCnDESwpXDgA3CmcKEXsKMIcOwwprCiQDClR3DnGUkw43DpMOHOMK7KlLDs2pJwr7Dj8OFMMObecOMw7PCpMKcW8OewoYjwrzDmXrCiWrDs0YKwonCrEbCt2rDmsOawpXCu8KmGRTDjlIqacKuwofDiCk4w4jDiMOvXsKke8OiwrDDiMKJdwPCtEUZw6ojD8OyGQ7DoMK1w4RxVGnCrhHDm8OjKhzDkcOAw6NWWcOGXsO3w6XDshzCohAZDBF+wop3w5UPKcOnEirDrE8SNMKew63CpUzDp8OiwoQ2wpPDiknClCIow67CmSFgO1zCncKSUWtUDcKow5nDkCtsdkzDg0cFd1UpNsKIw5rDq8K/LkHDrQHDuXkJwosTwrXClgvCnDnDuMOZOsKrZWdew5JIXsOhw6ghw4s3BMOUw4LCp8KRPRMfwqbDn1Yiw6BjwpYsO2g9XU/DvMOcdMKDYVzDucKOHxBXPVQPw6DDlGQKw7zDpMK6wpPDiw9Ffm7CsTLCpn/DpG7DpwjDt00kMMOgGsKRwofDjsO+w6XCi1TCtVjDll5AecKVaBBlPsOiw61HXHnCkXPDj20Gw6nChkDDmhzDiikMw70QYMOyGsO7w5nDjyHCo8O0UcKgw6bDqMOmTcOyw5I0Dj3CixUeTcOMw5LClsKDJMKubFwTVMOew7DDkkvCgsKpb8OPw5obZgLCnVrCjSnDt8O0w73Cv8KFSsOUw40uBznCnn5Fw6VDw5PClAddIMKGwrFlw43CuzsCw6fDijQ7w7bDu8K3d15Uw47CkxsFHXtvw5FRwpQ1Ii4JUi8JcELCmMOyw4oPw5HDpmPDksO9wqfCgsKObsOlf8OFdEEaaTbDtcO8asKmw43DhMKbKsOpw4bDskY1w4ZhBMKESh/CucKocSnDjgXDhz3Cr0TDnsOuw64HC8Kjw7ZfaAMhw4fCqBTDocKQSDgfHcOAw6/Dt8O7wrDCjsKDw5LCm8KgBcKHw6zDpgrDmAQ/KSNrwqQcRsO9w7EAXEg+wr3Cjh3CksKEw6/Dt8OyV30fI8ODw4fDvsKaw5vDggoJwowI";
	var key1 = Encoding.UTF8.GetString(Convert.FromBase64String(key1base64));
	key1.Length.Dump();  // Outputs "1001"
	persistentDictionary[key1] = "Foo";
	persistentDictionary[key1].Dump();  // Works!

	var key2base64 = "TxHDimbDjxbCssKRMnzCo8KSUgMzwpwvGMOSwpg7w7B0WTrDrB13wpMOwqs7fsKSw6/CgMKFJk7CrcKoTsK9w6BEw4TChMOYwrgcAHhvAgRewpxwLMOiw7k6w70kw5BnFMOAFMKzFwnDiSTDr8OsMsKTFHZoRMK/dw4zw4x8wo7CkMOjFMO5bMK0blHCmRDDncKvw4TDhAUEw7bCrkoSFywJW8K2esK0esKFFcKdwprCmDLCg8OPAhBdb8KAwpvCmcKDN8OGwqN/wrpyF8KEwoJpdmTDmsK4QsOxw7/DtMOLwoNzQhfCkkE1AcOmUcObwpF8wpPChSTDsMOXNcK/E8O+GBguwrsfw7VJw41rcMKMw5AVEMO1wq4QPsKFcTAzwqfDl8O5w5FUwpRSGsOKNMK4woVbKcOpw5YhP8K3GcOlawXCrH11LkLDhsO3OsKiw43DpHFWw4JNwqHCtXtRwqVXGMKPwrXDi8OFOhxFwrkXTjvDkk1Tw59lD1TDk8O5FcK4dsK4wpIUw5PCngLCncKUw4XCrcKUw67DgGN9wozDmsO1w6jCtsKWNcKEdMO6w4JPa8O8w5JeAsOXPhMyJUjCp8K2ecK6diTCuWQeAsKSw4jDuAQtAsOgwoIOwqDDmcObwrMywpfDsk/CkRfCgVBKZsKSTTI8w5vCv1/Cu8KVwqNMw5g0w5pZw5XDlF3CkCTChW/DiwJGIsKDw5UnTcKdwrFIYWbCtsO6w4UEw4PCrsOkQzhmWWIYw7XCvEIjwr8mw6EjwoIww7XCuTvCisKTSAXCmsKQw5N0wqPDmg5Zw412wqArwpLCm8Oswr9rw59qCnnDsiJ/QjTDisOPS8KII1HDuzLDi8OJwo/CpFLDojPDisOxwq9Aw7fDr8KUCMO5w4/Cqyg+wovCqG5TMW4QPg1FU04wYMOPIzDDh8KNwojDlsKvAXI+SkQ1w4dRwrh3KMK9wqYjWztzw6PDkcO0wrzCq1zDscOHwo/DhcOlw4gIHsKgZ8OcwqfDuxTDpirDmnfCvMKNw5smcsK5wqvDh8O1VMKpwrbDocOzVRZMwoPCtXDDocKJwrBZwohVw4p8XybCjMK5w7Z9AB7CgMOLVcOWGR3Dk8K0dMOpwoXDqFLDpcOIY3RqwpYyw53CgsKdHcOuL2jDjsOHw7DDgGTDszbClcKBLcOfV8OEwrXDu8Okwp/Dj8OhKnpeKUTCjMOmw41Bw74uN8Onw6nCtQTDrcKEKCHDtRtPRjXClRPDkn3DocKdw75NDAXDrXDCncKrNH0lw7XCllPDtsO3bg7CsQ5fdsKuw6wOKhfDtMKveBRQX2Avw6rDmsOjw4jCk0/DmcO0wqPDkCbCucOzP8KdwqXDg8OLw5M+wofCnyDDt8OCWMKpw7zCu2nDlcKVNSMLHcKKRh3CvsKGwoIKHMOocSPCtRLDk1DChMKMIsKnS8K6w6wFO8Kmw5w5OsO6wpDCg8OQM8KAGn3CrhTCtwXClAQOUTXDs8Opw6cYUQkTe8OAYsKdQMOiGMKpSMOQIVjDrVPCgcKRwrnDk8OVd2vCosK2wrbDnsKzBcKyw7NRIcKpwodwVXIdfTzDjMO8DcK8w4TDosK2Y8OhcVcuRXvCkcKnw5kKwqzCv8KNw5xlwrbDt8KueMORfcO+D3Q7wpYJe13DpcOyw5MnUCRAwpsjw5wuw7XDiHtoccK9wq/Dr8KXV8OFFWrDpcOlw6Niw6PDssKucRZKw7MXw5jClzzCuCQbw5PDkknDm8K1woLCpgJ9w6caw6QFH8OdaEJqQMOewrcwLcK8w599wohQwpglcjdyO8OxQyAJMGHCu8OgdMOHVzFEw5M6b1XDkXdGZMKiwqTCjMO7N8O5VmpYdMOiccOJLcKZSDg6w58iw5bCvGVlwq04wrQWKMOQwqHCvyzDl0/CnsKTDcO4Z2V2HFN0w4B7wqXCoCcdwpfCmCPCjcOmPiZOw79FP0HCh8OSIkXDscOew7vCtCpCeMK9";
	var key2 = Encoding.UTF8.GetString(Convert.FromBase64String(key2base64));
	key2.Length.Dump();  // Outputs "1001"
	persistentDictionary[key2] = "Bar"; // Works first time code is run. Throws EsentKeyDuplicateException second time code is run.
	persistentDictionary[key2].Dump();  // Throws KeyNotFoundException first time code is run.
}

Any ideas on what might be causing this? I couldn't figure out any pattern among successful or failing keys.

DLL version is 1.9.4 for Esent Collections, Interop, and Isam.

Cheers,

Jeremy

Esent & VirtualAlloc Calls - Memory Leak?

We are using the ManagedEsent lib and therefor Esent in our desktop application. It is used as a Cache to store all kind of data (e.g. user data like names or binary stuff like images and larger binary stuff like word documents etc.
The library served us well for the last couple of years.
Recently 2 customers noted that some clients are demanding more and more memory. Both customers use Citrix and our first thought was, that it must be something wrong with Citrix. Unfortunately the issue can't be easily reproduced - it is not always the same user and we couldn't find a pattern.

After hours of investigation we finally could get a Windows Performance .etl file and it seems that esent claims more and more memory:
image

Line #, Process, Commit Stack, Commit Time (s), Decommit Time (s), Address, Count, Size (MB)
2, , [Root]/ntdll.dll!RtlUserThreadStart/kernel32.dll!BaseThreadInitThunk/ntdll.dll!TppWorkerThread/ntdll.dll!TppTimerpExecuteCallback/ntdll.dll!RtlpTpTimerCallback/esent.dll!COSTimerQueueEntry::Completion_/esent.dll!BFIMaintCacheSizeITask/esent.dll!ErrBFICacheGrow/esent.dll!ErrBFICacheISetSize/esent.dll!ErrBFICacheISetDataSize/esent.dll!OSSYNC::FPageCommit/KernelBase.dll!VirtualAlloc/hmpalert.dll!<PDB not found>/ntdll.dll!NtAllocateVirtualMemory/ntoskrnl.exe!KiSystemServiceCopyEnd/ntoskrnl.exe!NtAllocateVirtualMemory/ntoskrnl.exe!MiAllocateVirtualMemory, 0.885232700, 1.683456200, 0x0000028B9C2D0000, 1, 512.000

The CPU is also quite busy with those calls:

image

Be aware, that this is a server with "lots" of memory, but one client that claims all memory is problematic.

Question: Do I read the etl file correct and that "esent" seems to be the root cause of the memory allocation? What does "BFIMaintCacheSizeITask" and "ErrBFICacheISetSize" do? I couldn't find anything and maybe someone from the ManagedEsent team knows more.
I found a property CacheSize (Docs), but I'm not 100% sure if this would solve the problem or how to apply it - I can't find in the Microsoft.Isam.Esent.Interop.Instance - InstanceParameters-Property.

Support for additional JET parameters

Hello, I stumbled upon several JET parameters not being exposed through the ESENT Interop API, including the following ones:

I wonder if support for these values could please be added.

These and other useful parameters are also missing from the autogenerated IsamSystemParameters class, including AlternateDatabaseRecoveryPath and LegacyFileNames. It also exposes the EnableIndexChecking parameter as int instead of bool.

Actually, the entire Microsoft.Database.Isam.IsamSystemParameters class should rather be replaced by the Microsoft.Isam.Esent.Interop.SystemParameters class, as it only duplicates its functionality without any added benefit IMO.

Keys are at most 2000 bytes but limit is not enforced

When you add items with long keys (I used ODATA Urls as key which can become quite long) it is acceptable to add keys longer than 2000 bytes. The AllKeys also works fine.
However when you use Contains or TryGetValue then this key cannot be found.
After some source code inspection it turned out that there is a constant Microsoft.Isam.Esent.Interop.KeyMostMost with a value of 2000 so the Cache class does not work properly. A possible fix would be to change the debug check in the Microsoft.Isam.Esent.Interop.MemoryCache.Duplicate method should be enforced at runtime.

PersistentDictionary, case sensitive comparer?

It seems that PersistentDictionary doesn’t take a comparer for the key.

So adding “one” and followed by “One” generates an exception.

Is there any way to introduce a case sensitive comparer?

Figuring out when PersistentDictionary is flushed to disk

So we have been having an issue in production with user sessions not being present in the PersistentDictionary after an obscure exception crashed the API.

After exhausting almost every avenue possible the only thing I'm left with is that whatever changes are made to the dictionary do not have a chance to be persisted to disk before the process Is terminated. Is there any way to tell, via logging or otherwise, when a none manual flush occurs? Please correct me if this isn't how it works but that's what I gather from the docs.

Thanks in advance

PersistentDictionary - Incompatible with NET 4.5

Hello,

I'm not able to build my .NET 4.5 project since the ManagedEsent libraries are compiled against 4.6.2. How can I make this work?

The primary reference "Esent.Collections, Version=1.9.4.1, Culture=neutral, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "Esent.Isam, Version=1.9.4.1, Culture=neutral, PublicKeyToken=null" which was built against the ".NETFramework,Version=v4.6.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.5.2". FileParserPOC

x64 ?

how can i run it in x64?

On .NET 5 changes in a PersistentDirectory aren't persisted unless Dispose() is called

Hi,

I'm not sure whether that's to be expected, but it's different on .NET Framework, and the documentation doesn't emphasize that Dispose() needs to be called to persist changes, so I'm reporting it.

To reproduce this, you can use the sample code from the documentation. While a .NET Framework build of that code works fine for me, a .NET 5 build doesn't store any names in the database:

C:\PersistentDictionaryTest-5>bin\x64\Debug\net5.0\PersistentDictionaryTest-5
What is your first name?
Foo
I don't know you, Foo. What is your last name?
Bar

C:\PersistentDictionaryTest-5>bin\x64\Debug\net5.0\PersistentDictionaryTest-5
What is your first name?
Foo
I don't know you, Foo. What is your last name?

For this repro I've been using the Nuget package of Microsoft.Database.Collections.Generic, version 2.0.2

Calling Dispose() on the dictionary at program end fixes the issue. So it might be related to .NET Core / .NET 5 not calling finalizers at program exit.

Termination in progress exception

Hello,

I am using ManagedEsent in my project. I need to do something on different databases in one process. Think a simple ui which has a button which takes a path from user that includes a valid database file (x.edb) and then do the following:

Create an instance ( with the same name in every call)
Set some system parameters (circularlog, SystemPath, LogFilePath vs)
instance.Init()
BeginSession (using instance)
AttachDatabase (sample project says that "Redundant Attach calls are safe")
OpenDatabase
OpenTable
BeginTransaction
Some delete, insert operations
CommitTransaction( with CommitTransactionGrbit.None - I also tried other two options)
CloseTable
CloseDatabase
EndSession
Terminate instance ( I tried both JetTerm and JetTerm2 api with different TermGrbit options)

After calling this function 1-4 times successfully, a following call throws
EsentTermInProgressException (Termination in progress) at any line of method. (sometimes deleting a row, sometimes closing table, sometimes closing database).

OS: Windows 7 Enterprise 64-bit
Using .NET 4.5

Is this a known issue or am i missing something ?
Could you please help ? Thank you...

ArgumentOutOfRangeException in RssDictionarySample

Hello
I'm trying to run RssDictionarySample, but I get the ArgumentOutOfRangeException in line 49, when creating a new PersistentDictionary.

Unhandled Exception: System.TypeInitializationException: The type initializer for 'RssDictionarySample.TrivialRssReader' threw an exception. ---> System.ArgumentOutOfRangeException: Not supported for SetColumn Parameter name: TColumn Actual value was RssDictionarySample.RssFeedData.

it seems that ESENTCOLLECTIONS_SUPPORTS_SERIALIZATION is not defined, so how do I use a custom struct for a PersistentDictionary value?

Nuget package Esent.Collections.dll missing since v1.9.0.1

Hi,

i see that since v1.9.0.1 Esent.Collections.dll is not included anymore in the nuget package.
How's this? There's another package to include or it's just missing?

I'm using PersistentDictionaries so i need to reference collections too.

Windows 11 support

The most recently available version does not work when attempting to access ESENT databases from Windows 11.

The error generated when attempting the call Api.JetAttachDatabase is:

InitializeConnection failed to initialise ESE database - Database engine is incompatible with database

Any ideas if/when this will be updated?

Thanks

How do we convert this to use persist reference objects

I understand that there has been a choice not to support persisting reference objects but how do I achieve this if I choose to? There is at least one Stack overflow article that suggests this is a simple fix but the fix suggested does not work.
Can anyone answer how this should be achieved? This seems like a common problem. Can we create a separate class that can do this. Perhaps the "PersistantDictionaryForObjects"

EsentVersion does not support 8.1 or 10 features on Windows 10

I'm on the Windows 10 FCU, I haven't tried on any other version of Windows.

If I start a blank dotnet solution and add the ManagedEsent 1.9.4 NuGet dependency, I see the following values:

EsentVersion.SupportsVistaFeatures = True
EsentVersion.SupportsWindows8Features = True
EsentVersion.SupportsWindows81Features = False
EsentVersion.SupportsWindows10Features = False

Are the 8.1 and 10 features no longer supported on Windows 10?

using Microsoft.Isam.Esent.Interop;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(EsentVersion.SupportsVistaFeatures); // True
            Console.WriteLine(EsentVersion.SupportsWindows8Features); // True
            Console.WriteLine(EsentVersion.SupportsWindows81Features); // False
            Console.WriteLine(EsentVersion.SupportsWindows10Features); // False
            Console.ReadLine();
        }
    }
}

App.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
    </startup>
</configuration>

packages.config

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="ManagedEsent" version="1.9.4" targetFramework="net461" />
</packages>

Assembly signing

Hi.

I faced a build error that complains the Esent.Collections does not have strong name.
I think that the most packages distributed on nuget.org have strong name.
Do you have any reason that you don't sign your assemblies?

If you don't have any critical reason, could you sign the packages which you distribute after next version?

Or else, could you let me know how avoid this build error?

Question: How to properly use esent session on different threads

Normally esent sessions are bound to thread on which they're created. Any attempt to use session on different thread results in exception. Although there is an API method to temporarily bind session to different thread, so session could be used from such thread without exception.

But this particular feature is poorly documented.

public static void JetSetSessionContext(
	JET_SESID sesid,
	IntPtr context
)

context
Type: System.IntPtr
The context to set.

The meaning of "context" argument is unexplained and there is nowhere to find a clear explanation what it really means and what should be used for the "context" value.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.