sanketplus / go-mysql-lock Goto Github PK

If Release() is called twice, the second time will block forever. It would be preferable to return an error or ignore the second call.

A typical usage of the library would be like this:

lock, _ := locker.Obtain("foo")
// do something
lock.Release()

However, lock.refresher() may call lock.Release() if PingContext() fails. Therefore, it is impossible to know if it has already been called and write safe code that only calls once.

GET_LOCK has subtleties like it the function is unsafe for statement-based replication. Find and document them all

Currently, a goroutine periodically pings on the connection that holds the lock. If a ping fails, it bails out and closes the connection.

1. Confirm what happens to connection when a ping fails
2. If connection is still kept in pool, consider multiple ping retries before giving up (and possibly make it configurable)

Hello,

Would it be possible to create a v0.0.5 tag from the current state of master. The company I work at prefers to use tags in our module versions rather than using whatever is on master and we want to use some of the improved error handling that is in master but not in v0.0.4

Thanks

There is currently a go-routine leak when spawning a refresher goroutine go lock.refresher(l.refreshInterval, cancelFunc) due to the use of an unbuffered channel unlocker: make(chan struct{}) , as in l.Release() called after connection ping fails due to cancellation of connection context, as there is no consumer listening to the channel l.unlocker <- struct{}{} while calling release goes to an infinite deadlock wait.

Using unlocker: make(chan struct{}, 1) should fix this deadlock.

I got my application hung after doing a load test. I dug into the library code and see that the database connection is not closed (return connection to the connection pool) if unable to obtain the lock.