- This topic has 10 replies, 8 voices, and was last updated 17 years ago by
.
-
Topic
-
This morning, I found lots of messages in Error db and I have never seen this before. It’s been running FINE until this error was encountered and now everything since then has been errored out and nothing was able to flow between our lab system and clinical system. All processes/threads were running fine and just found whole bunch of these messages in error db. What is the problem and how do I fix it?
[xlt :xlat:ERR /0:
-
Replies
-
-
-
-
-
Hyunyoung, You probably need to incorporate some re-try/error logic with respect to opening the database; if it attempts to open the database while it is open for write, then an error will be returned. You can do something like this:
#This code keeps attempting to open the database until successful #
set retcd 1
while { $retcd } {
set retcd [catch {gdbm_open $db_name}]
}
# End of open loop #
Hope this helps.
Jim Cobane
Henry Ford Health
-
-
To view gdbm database content: from hcitcl execute the regular GDBM commands. Keep in mind that the database must be open first, before executing any other command and while the database is open, the tcl will not have access to it, so it is not a good idea to keep a production database open for viewing. To close it:
hcitcl gdbm_close /pathway/dbname
Examples of gdbm commands:
gdbm_list /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db # lists all keys in the db
gdbm_store /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key content # writes into the db
gdbm_close /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db
gdbm_firstkey /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db # reads first key in the db
gdbm_nextkey /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key # reads next key
gdbm_delete /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key # deletes a key from the db
gdbm_fetch /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key # reads a specific key
-
-
-
We have been using gdbm quite successfully for several years, but be warned. Working with gdbm can cause your hair to turn grey. You can open a database for writing (single-user mode) by only one instance of the tcl interpreter. If it is not open for writing, you can open it for reading (multi-user mode) by many instances.
You must have created the db file before you attempt any gdbm_open calls.
If you are placing the gdbm calls inside multiple xlates you will be fine as long as they are in the same CL process, and you add some code to make sure you don’t attempt to open it more than once. You will want to open it for writing. Opening the db only once within the process is fine. If using this inside xlates, you do not need to close the db.
If you are placing the gdbm code inside tcl procs for use outside the xlates, you have to implement your own file locking. For “multi-user access” the best option is to use tcl’s
flockcall. (Go to hcitcl and say “help flock”.) You cannot use flock directly on the database file so you must create a semaphore file that you use flock with. Then you must write your code so you always access the semaphore file with flock before trying to open the gdbm database. After your access, use the gdbm_close call and then call funlockon the semaphore file. Use this flock/open/access/close/funlock sequence for each db access so all instances will have equal opportunity to access the db. When using flock with multiple files, particularly in multiple routines, always open and access the files in the same sequence and close them in the reverse order (unwind) so you can avoid deadlock problems.
When implementing the flock calls you use the options -read and -write. This allows multiple tcl instances to access the db for reading yet make them wait if an instance wants to open the db for writing. It also makes the write job wait if anyone has the file open for reading.
You can certainly play with this and test it by opening two telnet sessions, firing up hcitcl and entering the commands manually. You will see how access to the db by the two instances is controlled.
Email me if you would like some sample code.
-
I like gdbm. It’s quirky and fun. You don’t say what version you are using, but starting around 5.3 rev something (we use AIX 5.3 Rev 2) a new process appeared: hcigdbm
If it is running, try killing it and running the script below from the hci command line. (Also, stop processes that use xlt_query_gdbm first.)
Code:
#!/hci/qdx5.3/integrator/bin/tcl
#
# test_gdbm.tcl
#
# Run this as the hci user before
# starting processes that use gdbm
# commands. This makes sure the
# hcigdbm server is operational.
#set DBNAME TMP_TESTGDBM.dbm
set TESTVALUE “test value [clock format [clock seconds]]”gdbm_open $DBNAME wc
gdbm_insert $DBNAME testkey $TESTVALUE
gdbm_close $DBNAMEgdbm_open $DBNAME r
set value_read [gdbm_fetch $DBNAME testkey]if {[string compare $TESTVALUE $value_read] == 0} {
puts “SUCCESS: $TESTVALUE”
} else {
puts “DID NOT WORK”
}file delete $DBNAME
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
