XMLSERVICE Ruby Tony Work Archive

Archive discussion (unused)

This material is not longer used … because we see pool is manged by ActiveRecord::ConnectionAdapters::ConnectionPool (Thanks for research Aaron your are a life saver).

Options …
1) GIL — ibm_db override GIL, thereby GIL freeze activity to DB2 one-at-at-time (current)

#ifdef PASE 
#define rb_thread_blocking_region pase_forget_blocking_region
int pase_forget_blocking_region( void * helper, void *args, void *UBF, void * stmt_res ) {
  int(*go)(void *) = helper;
  /* printf ("Lucy i'm home ...\n");*/
  return go(args);
} 
#endif
Pro:
- simple model ... at least until Ruby changes GIL
Con:
- slowest choice ... all DB2 operations halt Ruby for one-at-time

2) connect lock — add a ibm_db connect lock to synchronize DB2 one-at-a-time

<=== job client ============>                                        <=====  job(s) server DB2 proxy (QSQ) ======>
Ruby PASE client -> thread 1 <profile Tom connection memory shared   > QSQSRVR (db2 proxy)<-.
                 -> thread 2 <profile Sally connection memory shared > QSQSRVR (db2 proxy)  | SHARE OK
                    :                                                                       | "ibm_db connect lock"
                 -> thread 3 <profile Tom bad fix "share connection" >----------------------.
                    :
                 -> thread n <profile Lisa connection memory shared  > QSQSRVR (db2 proxy)
Attributes of "server mode" multiple jobs:
- profile ibm_db connection established a transaction boundary using an attached QSQ server job for "isolation"
- "connect usage" lock to ibm_db structures, whereby only one request is running client<IPC-one-at-time>server
Pro:
- ruby developer oblivious to any "share" across threads (mmm ... dumb user)
- GIL released will allow Ruby interpreter to keep on running other threads
Con:
- requires a new lock at application level (evil really)
- deadlock/hang possibilities increase (customer shoot self)
3) freeze connection to thread — ibm_db “freeze” any given connection to a specific thread.
Ruby PASE client -> thread 1 <profile Tom connection 1 memory shared   > QSQSRVR (db2 proxy)<- thread 1 locked
                 -> thread 2 <profile Sally connection 1 memory shared > QSQSRVR (db2 proxy)<- thread 2 locked
                 -> thread 3 <profile Tom connection 2 memory shared   > QSQSRVR (db2 proxy)<- thread 3 locked
                 -> thread 4 <profile Sally connection 2 memory shared > QSQSRVR (db2 proxy)<- thread 4 locked
                 -> thread 5 <profile Sally connection 3 memory shared > QSQSRVR (db2 proxy)<- thread 5 locked
                    :
                 -> thread n <profile Lisa connection memory shared    > QSQSRVR (db2 proxy)<- thread n locked
Attributes of "server mode" multiple jobs:
- profile ibm_db connection established a transaction boundary using an attached QSQ server job for "isolation"
- each profile can have many different connections client-thread-n<freeze>QSQSRVR 
- "freeze usage" lock to ibm_db structures, whereby NO LOCK is needed
- Java uses this idea for "pool of QSQ" without requiring re-attach QSQ pool (2x - 10x faster)
Pro:
- no locks at application level runs faster, but requires "smarter" users
- QSQ can be pooled without release to QSQ pool (2x - 10x faster)
- deadlock/hang not likely
- GIL released will allow Ruby interpreter to keep on running other threads
Con:
- "freeze usage" lock to thread, violation results in error message "wrong thread connection frozen to thread n"