interesting notes there... i was a bit confused as to which to choose, theres dbm ndbm gdbm....!!!
i haven't compared performance btwn them, all i can say there is satisfactory performance with the gdbm, on some of our binds the gdbm file has grown to MBs - theres orphaned DLRs going [EMAIL PROTECTED]@ - anyway there doesn't seem to be any speed issue i'm aware of atm but i haven;t measured it either. the plus for it is that it is very esy to setup, if your kannel is fairly much self contained,and u don't need application to be quering the dlr storage, ie if using mysql,oracle etc etc, then gdbm is a reasonable solution. One hiccup tho is that with one of our service providers whom we have multiple binds with, sometimes send the DLr back on a different bind - well that stuffs up finding the dlr to match up in the db store because each kannel instance has a separate db store file - i guess you won't have that problem if using mysql etc. However 99% of msgs get dlrs resolved on the same bind, for those that fall thru,by passing the messageid back to app to resolve them works out for us. gdbm doesn't implement any kind of locking, so need to implement your own locking, gwlibs mutex_lock works ok for that. ** Each kannel has its own db store file, so not worried about locking across processes. ** Dave i'm just updating my code to work with a version of the latest kannel - a painful process of merging our differences (not just gdbm, thats easy as the dlr storage is as best virtualized as C can do), and a routine to find old orphaned records, so if you can wait just a bit... Cheers fred ----- Original Message ----- From: "Dziugas Baltrunas" <[EMAIL PROTECTED]> To: "Davy Chan" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, February 22, 2005 6:46 PM Subject: Re: resubmit your dbm/gdbm-based DLR storage patch and vote to phase out internal DLR storage in favor of DBM DLR storage -#- MailID:PAAA > Hi, > > > Now that we have UUIDs for each SMS passing through the bearerbox, > > would it be possible to modify your code to use standard dbm instead > > of gdbm. That way, it could be compiled easily on most standard > > platforms. For those wanting better performance, they can compile > > using gdbm in dbm compatibility mode. If you don't have the time, > > then I would like to take over your code, modify it, and submit it > > for voting. > > As far as I'm experienced with both GNU dbm and Berkeley's DB (1, 2, > 3, 4 and now 5), the last one really outperforms the first one in > several ways. Some years ago my tests showed that there is no problems > while multiple threads are reading and writing (called concurent > reads/writes) to the same BDB because of it's good and fast locking > mechanisms. In contrast, GNU dbm complained about "database is in > use". > > Although sometimes it's necessary to play with LDFLAGS/CFLAGS while > compiling application with BDB, I give my +1 for user to choose the > libs in the ./configure stage as you've suggested. > > -- > regards, > Dziugas Baltrunas >
