Oracle 12 unmanaged ODP.NET Driver memory usage

Posts   
 
    
greenstone
User
Posts: 132
Joined: 20-Jun-2007
# Posted on: 01-Apr-2016 05:33:26   

We have a Windows service application that process and import file and inserts the data into an Oracle database using llblgen.

Everything works great on all test machines and servers in our environment, using either the Oracle Managed or Oracle Unmanaged ODP.NET drivers

At our customer site, when they use the Managed driver, all works ok. However, they cannot use the Managed driver in their production, because Oracle doesn't yet support the encryption security level they require...only the Oracle ODP.NET unmanaged driver apparently supports this encryption requirement at this time.

The problem is the customer is reporting extraordinary memory consumption, and out-of-memory errors when running our application (using LLBLGen 4.2) using the ODP.NET unmanaged driver.

Because of this, we've also built a 64-bit version of our application (to give access to additional memory space), but they are still reporting out-of-memory exceptions.

Any hearing of memory consumption problems with specific installations of the Oracle 12 unmanaged ODP.NET driver?

Thanks!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 01-Apr-2016 10:23:50   

(I assume you're using adapter)

ODP.NET unmanaged ado.net provider is a wrapper around their (massive) java based client-level interface. Due to this, every .NET object created through ODP.NET wraps a java object. This requires that every object is disposed to free up the java object.

It's therefore essential that you call Dispose() on all DataAccessAdapter objects. if you fetch datareaders, it's key that you dispose these as well. We went to great lengths to make sure things are disposed properly, even parameters (as in the v1.x era we had a leak there with ODP.NET).

That said, out-of-memory can happen because of a lot of things. If at your client the managed provider gives out-of-memory as well, it might also be your application fetches too much data (e.g. thousands of entities, large sets, which are kept in-memory for a long time) and keels over because of that. It also might be, due to the fact ODP.NET unmanaged wraps java objects, the amount of memory given to the JVM is too small (the JVM can be given more memory, per process) and it goes wrong because of that.

If, with the given dataset the app works with, the managed provider works fine and the unmanaged doesn't, and the JVM is given enough memory, I'd look into your code whether you dispose all adapters properly as otherwise they leak (the finalizers might not run for a long time)

Frans Bouma | Lead developer LLBLGen Pro
greenstone
User
Posts: 132
Joined: 20-Jun-2007
# Posted on: 01-Apr-2016 20:16:34   

Thanks Otis.

Yes, using "adapter" of LLBLGen 4.2.

On making sure to call dispose, is the "Using" syntax is sufficient to do this?

Using adapter As SD.LLBLGen.Pro.ORMSupportClasses.IDataAccessAdapter

...use the adapter

End Using

Is there any need to do an: adapter.CloseConnection(), or is the "End Using" sufficient?

For our case, the Managed Oracle ODP.NET works ok. Only the Unmanaged Oracle ODP.NET is giving the out-of-memory error. We'll go through all the DataAccessAdapter objects and DataReaders to make sure they are disposed.

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 02-Apr-2016 07:08:32   

greenstone wrote:

On making sure to call dispose, is the "Using" syntax is sufficient to do this?

Using adapter As SD.LLBLGen.Pro.ORMSupportClasses.IDataAccessAdapter

...use the adapter

End Using

Is there any need to do an: adapter.CloseConnection(), or is the "End Using" sufficient?

Ending the scope is sufficient. Check: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=4460

greenstone wrote:

For our case, the Managed Oracle ODP.NET works ok. Only the Unmanaged Oracle ODP.NET is giving the out-of-memory error. We'll go through all the DataAccessAdapter objects and DataReaders to make sure they are disposed.

Does this happen with the same application code? Did you check with a memory profiler to see where is the memory consumption problem?

David Elizondo | LLBLGen Support Team
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 02-Apr-2016 09:27:38   

indeed, it might very well be JVM related, as the unmanaged provider uses java under the covers, so JVM memory settings are important.

Frans Bouma | Lead developer LLBLGen Pro
greenstone
User
Posts: 132
Joined: 20-Jun-2007
# Posted on: 02-Apr-2016 15:11:09   

Yes the out-of-memory issue occurs with the same application code and a identically sized data set in the database. Summary (running the same application code): My test setup: ODP.NET Managed - works fine, ODP.NET Unmanaged - works fine Custom test setup: ODP.NET Managed - works fine, ODP.NET Unmanaged - excessive memory usage

I can't really run a memory profiler, because I can't see problem here. I'll might try to figure a way to have the customer run a memory profile.

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 03-Apr-2016 18:00:06   

For what you say, it seems that it's actually a JVM/machine issue. Please investigate with a profiler and let us know when you found something interesting, or something we should take care of.

David Elizondo | LLBLGen Support Team