PASS
ok      github.com/volker-raschek/locker        1.479s

I'd use context.Context (for timeouts) and defer tx.Rollback().

What do you want to test?

In a Go program, you won't create more sql.DB pools per database, only one.
Here you create 25.

Maybe I've found a fix for the empty errors - see 7c96931

For your tests, I'd use context for timeouts:
x.patch.txt

Hey @tgulacsi ,

I should give you more information. I am writing a backend application in go
which will be packaged as container image. The container image is a base image
for other containerized applications which run in future in a kubernetes
cluster. One application, based on my container image, share the used database
scheme with other instances of the same application.

I don't know how ofter the application will be started in the cluster, but to
avoid that all instances of the application starts to migrate the database
scheme from one version to another an entry in table scheme_lock should avoid to
start the migration process multiple times.

This is also the reason for 25 instances of the sql.DB pools. Each sql.DB pool
for one running application. It can be possible, that in a cluster more than 25
instances of an application is running. Maybe 100 or 1000. I just do not know it
at the moment.

I applied your patch into my example project. I saw you implemented a mutex. I
think the mutex makes no sense for the same reason. I have n applications and
the mutex limits only simultaneous access exclusively for one instance.

Next to the context. I try to change the code to use a context. I can pass the
context over the Config struct for the oracle driver of the go-migrate package.
Ofter the Lock() and Unlock() function it is not possible. It is an
implementation of the interface.

• Config{} struct
• Driver{} interface

Now again to your patch. The test is successfully on my local system. On our
internal CI I received the following error message:

    locker_test.go:103: 
        	Error Trace:	locker_test.go:103
        	Error:      	Should be true
        	Test:       	TestLocker/Concurrency
        	Messages:   	Failed to create table schema_lock: dpiStmt_execute(mode=0 arrLen=-1): 
--- FAIL: TestLocker (0.79s)
    --- PASS: TestLocker/lock-unlock (0.57s)
    --- FAIL: TestLocker/Concurrency (0.22s)

Complete CI-Log

"Maybe I've found a fix for the empty errors - see 7c96931"

@sudarshan12s , thanks a lot for the hint with runtime.LockOSThread(). I added LockOSThread() into my test and I have updated godror to the latest version (currently v0.22.3). The test is than successfully on the CI. The logs are attached - ci.log

Since there is a dependency on a C library by godror it seems that it must be ensured that the C code runs in the same thread as the Go routines. Some additional links:

1. benefits-of-runtime-lockosthread-in-golang
2. LockOSThread - example

Now I am wondering how far this could have implications on existing code where runtime.LockOSThread() is not called.

I think this is only necessary when an application opens multiple DB pools or did I misunderstand something?

I still does not understand what's happening.

@volker-raschek , can you post us a failing CI log of yout test using v0.22.3, but WITHOUT runtime.LockOSThread() ? That should not have empty error message.
If it still does, than that suggests that the error-retrieving logic must be protected with LockOSThread(), which is more than a hundred places in the source, so I'd like to support this with evidence.

@volker-raschek can you try 8411931 without runtime.LockOSThread ?
I've tried encapsulating all OCI execution and error return in runtime.LockOSThread.

@tgulacsi, I updated godror to 8411931 and removed runtime.LockOSThread() from my test - commit

The test is now successfully on the CI - ci.log. I would like to update all of our internal projects to the latest version of godror if we have fixed the error.

@sudarshan12s , thanks a lot for the hint with runtime.LockOSThread(). I added LockOSThread() into my test and I have updated godror to the latest version (currently v0.22.3). The test is than successfully on the CI. The logs are attached - ci.log

Since there is a dependency on a C library by godror it seems that it must be ensured that the C code runs in the same thread as the Go routines. Some additional links:

1. benefits-of-runtime-lockosthread-in-golang
2. LockOSThread - example

Now I am wondering how far this could have implications on existing code where runtime.LockOSThread() is not called.

I think this is only necessary when an application opens multiple DB pools or did I misunderstand something?

Yes i was indicating TLS used for storing error context in C libs in this case. Other thing I wanted to clarify is on application instance. By application instance, you mean a seperate process , right? which creates a pool.
I got confused because in your test case, you create multiple pools in a single process .