Possible Oracle RAC issues?

Posts   
 
    
Posts: 77
Joined: 05-May-2005
# Posted on: 11-Sep-2013 18:29:21   

We are experiencing some strange behavior in our production environment. For instance, we are getting some partial commits even though the code is not issuing a commit until the end of a transaction. And we are getting out of sync exceptions that we have not seen before. The team is wondering if there are any known issues using LLBLGen with Oracle RAC. Here is our configuration:

LLBLGen Pro: v3.1 Final (June 17th, 2011) ORMSupportClasses.Net20: 3.1.11.427 Database: Oracle 11g RAC with SCAN ODP.Net: 4.112.3.0 (11g) Template: Adapter .NET: 4.0

Walaa avatar
Walaa
Support Team
Posts: 14950
Joined: 21-Aug-2005
# Posted on: 11-Sep-2013 19:10:19   

You said you haven't seen these issues before, right? Does this mean that with the same code and llblgen runtime libraries everything was working correctly and suddenly these issues started to appear?

How do you tell, that you are getting partial commits? Are you using a UoW? or a Transaction? or both?

My first recommendation is to use the latest release of the 3.1 runtime libraries, as it seems you are using an old version. And better to migrate to the latest release of v.3.5 (free upgrade and should be smooth upgrade).

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 12-Sep-2013 10:06:33   

Also check whether a multi-threading issue can occur: i.e. where you share entities, adapters or unit of works across threads e.g. through storing them into application objects of a website application/service application.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 77
Joined: 05-May-2005
# Posted on: 27-Sep-2013 20:19:58   

We have several staging labs where testing occurs prior to placing the applications into production. The staging labs do not use Oracle RAC; only production has that configuration. The applications work fine in the staging labs. It only fails in production and even then only occasionally. Can you tell me if you have any other customers who are using LLBLGen in an environment with Oracle RAC - especially Oracle RAC with SCAN?

Posts: 77
Joined: 05-May-2005
# Posted on: 27-Sep-2013 20:25:31   

This is slightly unrelated to this thread, but related to what we are doing to gather information to help us resolve this issue: We would like to log the ODP.Net version that is being accessed by the Oracle driver. How can we do that?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 27-Sep-2013 23:23:33   

jlkInChantillyVA wrote:

We have several staging labs where testing occurs prior to placing the applications into production. The staging labs do not use Oracle RAC; only production has that configuration. The applications work fine in the staging labs. It only fails in production and even then only occasionally. Can you tell me if you have any other customers who are using LLBLGen in an environment with Oracle RAC - especially Oracle RAC with SCAN?

I can't tell you because I don't know. We have many customers using Oracle and ODP.NET, but I have no idea whether they're using that specific setup.

About your other question: please check the machine.config file for the .net version you're using. In there you'll find the oracle dataaccess DbProviderFactory definition, which points you to the odp.net version utilized at runtime. The ODP.NET provider is a wrapper around the CLI java client in the Oracle HOME, in general the client installed with ODP.NET

Frans Bouma | Lead developer LLBLGen Pro
Posts: 77
Joined: 05-May-2005
# Posted on: 20-Dec-2013 22:49:04   

This turned out to be an odd problem that was pretty difficult to track down. We had an entity TransitAccountEntity that had an FK to a RiderClassEntity. One of the programmers manually retrieved the RiderClassEntity and set the TransitAccountEntity.RiderClass property using the retrieved entity. When the TransitAccountEntity was saved an ORMOutOfSync exception occurred even though it was not a recursive save and even though the RiderClass had not changed in the database. Anyway, we just modified the code to quit storing the RiderClass in this way and the problem was resolved.