search

fukamachi / cl-dbi

Database independent interface for Common Lisp
202 stars 28 forks source link

Functions connect-cached and get-connection-pool are not thread-safe #66

Open svetlyak40wt opened 3 years ago

svetlyak40wt commented 3 years ago

Because of that, Ultralisp sometimes fails with this error:

failed AVER:
    (= (HASH-TABLE-COUNT SB-IMPL::TABLE) SB-IMPL::HWM)
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
   [Condition of type SB-INT:BUG]

Restarts:
 0: [ABORT] abort thread (#<THREAD "searching-for-repositories" RUNNING {102F529873}>)

Backtrace:
 0: (SB-IMPL::GROW-HASH-TABLE #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}>)
 1: ((FLET SB-IMPL::INSERT-AT :IN SB-IMPL::GET-PUTHASH-DEFINITIONS) #<unavailable argument> #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}> #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F52987..
 2: (SB-IMPL::PUTHASH/EQ #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F529873}> #<unavailable argument> #<unavailable argument>)
 3: (SB-KERNEL:%PUTHASH #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F529873}> #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}> #<HASH-TABLE :TEST EQUAL :COUNT 0 {102F5305A3}>)
 4: (DBI:CONNECT-CACHED :POSTGRES :HOST "172.17.0.1" :DATABASE-NAME "ultralisp" :USERNAME "ultralisp" :PASSWORD "****")
 5: (ULTRALISP/DB::CONNECT :HOST NIL :DATABASE-NAME NIL :USERNAME NIL :PASSWORD NIL :CACHED T)
 6: ((LAMBDA NIL :IN ULTRALISP/GITHUB/WIDGETS/REPOSITORIES::SET-OAUTH-TOKEN))
 7: ((LABELS BORDEAUX-THREADS::%BINDING-DEFAULT-SPECIALS-WRAPPER :IN BORDEAUX-THREADS::BINDING-DEFAULT-SPECIALS))

This code short be protected with lock.

svetlyak40wt commented 3 years ago

As a workaround, you may recreate the hash from time to time:

(setf cl-dbi::*threads-connection-pool* (cl-dbi::make-threads-connection-pool))
fukamachi commented 3 years ago

Thank you for reporting. Adding :synchronized t to make-hash-table might work?

svetlyak40wt commented 3 years ago

As I understand, :synchronized t is SBCL's extensions and will not work on other implementations.

Probably we need a separate system to work this around? Something like trivial-sychronized.?

svetlyak40wt commented 1 year ago

As I see some sort of synchronization was already added: https://github.com/fukamachi/cl-dbi/blob/738a74dd69adb2a7c21fa67e140d89c7df25b227/src/cache/thread.lisp#L37

And today I've fixed it a little in this pull-request:

https://github.com/fukamachi/cl-dbi/pull/75