ODP.NET

Hi,

I have developed a WCF service that get data from oracle database 9x using Oracle Data Access Component. When I tested the service with a parallelism call I have noticed strange behavior when connection with database timed out (to test this I have changed connection port).

My client is a simple parallelism task service call:

static void Main(string[] args)
        {            
            try
            {                
                //TEST SIMULTANEOUS CONCURRENT SERVICE USE
                var taskParallel = new List<Task>();
                for (int i = 0; i < 5; i++)
                {
                    taskParallel.Add(new Task(() =>
                    {
                        try
                        {
                            using (var client = new PeopleServiceReference.PeopleServiceClient())
                            {
                                Console.WriteLine(DateTime.Now + " start task " + Task.CurrentId.ToString());
                                var p = client.GetPerson("peopleidentifier");
                                Console.WriteLine(DateTime.Now + " " + p.Nome + " " + p.Cognome + " on task " + Task.CurrentId.ToString());
                            }
                        }
                        catch (Exception ex)
                        {
                            Console.WriteLine(DateTime.Now + " exception on task " + Task.CurrentId + ". " + ex.Message);
                        }
                    }));
                }
                Stopwatch stopWatch = new Stopwatch();
                stopWatch.Start();
                
                Parallel.ForEach(taskParallel, (t) => { t.Start(); }); //START CALLS TO WCF SERVICE
                Console.ReadLine();
                Task.WaitAll(taskParallel.ToArray());
                stopWatch.Stop();
                // Get the elapsed time as a TimeSpan value.
                TimeSpan ts = stopWatch.Elapsed;
                // Format and display the TimeSpan value.
                string elapsedTime = String.Format("{0:00}:{1:00}:{2:00}.{3:00}",
                    ts.Hours, ts.Minutes, ts.Seconds,
                    ts.Milliseconds / 10);
                Console.WriteLine("RunTime " + elapsedTime);
                }            
            catch
            {
                Console.WriteLine("Error");
            }           

            Console.ReadLine();
        }

Now I have noticed that if service is configured with pooling=false, response of client is ok as it's shown:

01/06/2017 09:59:36 start task 5
01/06/2017 09:59:36 start task 6
01/06/2017 09:59:36 start task 8
01/06/2017 09:59:36 start task 7
01/06/2017 09:59:36 start task 3
01/06/2017 10:00:06 exception on task 5. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:00:06 exception on task 7. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:00:06 exception on task 3. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:00:06 exception on task 6. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:00:06 exception on task 8. ORA-12170: TNS:Connect timeout occurred

Output show that timeout throws for each service call in parallel mode, that is what I expect. For performance reason (high performance reason) I have enabled pool in connection string parameter with Pooling=true

Here I have noticed strange behaviour, as it's shown:

01/06/2017 10:16:27 start task 3
01/06/2017 10:16:27 start task 8
01/06/2017 10:16:27 start task 6
01/06/2017 10:16:27 start task 5
01/06/2017 10:16:27 start task 7
01/06/2017 10:16:50 exception on task 7. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:17:11 exception on task 3. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:17:32 exception on task 6. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:17:54 exception on task 5. ORA-12170: TNS:Connect timeout occurred
01/06/2017 10:18:15 exception on task 8. ORA-12170: TNS:Connect timeout occurred

In this example task number 8 had to wait wait for all previous task to complete timeout error response.

How can I solve this issue?

Thank a lot,

LucaG.