No subject


Wed Jun 24 00:39:36 CEST 2009


fallback mode:
init: load from database, keep data in tables
runtime: insert/update records in table on timer event
shutdown: flush cache to db

non-fallback mode:
init: load from database, empty table
runtime: no inserts but try to update table (won't work because table is
emptied)
shutdown: flush cache to db (fails, because all entries are marked
NO_UPDATEDB_FLAG du to the (failed) updates at runtime). Result is an empty
table after shutdown.

The documentation says in fallback mode the cache isn't used. This is
impossible in the current code. Later in the docs it is said only on cache
misses, the db is used. This seems reasonable behavior.

The main question is: should the db be updated during runtime or only on
shutdown when in non-fallback mode?


Attached patch creates the following behavior:

for both modes:
init: load from database, keep table contents
runtime: update/insert into table on timer event
shutdown: update/insert final time

The only difference in the modes is on lookup (as documentation says) and
is untouched by this patch.

The non-fallback mode should be optimized by not updating the table if the
answer to the above question says so, but that is not as trivial as this
patch.


ps. I found some nice descriptive function names: update_db_subs() and
update_subs_db()....



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 19:52

Message:
fallback to db is in presence and the insert function is used by rls module
as well. I had no time to check the impact now.

With this idea, to be safe, fallback2db param has to be directed to
another variable, fallback2db initialized to 0 and set to param value in
each child, via child_init. Otherwise can be a conflict of loading order.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:37

Message:
I don't know if changing the API and ABI is appropriate for the stable
series. 

What about setting the fallback2db variable only AFTER loading the DB
contents?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:22

Message:
The function is used in presence and rls modules. Does not look like big
changes to add a new param to specify the mode. Do you think of something
else?

----------------------------------------------------------------------

Comment By: Alex Hermann (axlh)
Date: 2009-07-20 18:07

Message:
New subscriptions don't get stored in the DB because the test for
'fallback2db' was wrong.

I just noticed the insert_shtable() function is also used to load from DB
initially, so my patch is wrong. Fix is a bit more non-trivial.

The problem is that the function is used for both DB-load at startup and
new subscriptions during runtime. The db_flag in the hash table record
needs to be INSERTDB_FLAG during runtime, and NO_UPDATEDB_FLAG for initial
load.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 17:53

Message:
Please provide a bit more details of what got broken.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_id=139143



More information about the sr-dev mailing list