1 |
root |
1.3 |
NAME |
2 |
|
|
BDB - Asynchronous Berkeley DB access |
3 |
|
|
|
4 |
|
|
SYNOPSIS |
5 |
|
|
use BDB; |
6 |
|
|
|
7 |
root |
1.4 |
my $env = db_env_create; |
8 |
|
|
|
9 |
|
|
mkdir "bdtest", 0700; |
10 |
|
|
db_env_open |
11 |
|
|
$env, |
12 |
|
|
"bdtest", |
13 |
|
|
BDB::INIT_LOCK | BDB::INIT_LOG | BDB::INIT_MPOOL |
14 |
|
|
| BDB::INIT_TXN | BDB::RECOVER | BDB::USE_ENVIRON | BDB::CREATE, |
15 |
|
|
0600; |
16 |
|
|
|
17 |
|
|
$env->set_flags (BDB::AUTO_COMMIT | BDB::TXN_NOSYNC, 1); |
18 |
|
|
|
19 |
|
|
my $db = db_create $env; |
20 |
|
|
db_open $db, undef, "table", undef, BDB::BTREE, BDB::AUTO_COMMIT | BDB::CREATE |
21 |
|
|
| BDB::READ_UNCOMMITTED, 0600; |
22 |
|
|
db_put $db, undef, "key", "data", 0, sub { |
23 |
|
|
db_del $db, undef, "key"; |
24 |
|
|
}; |
25 |
|
|
db_sync $db; |
26 |
|
|
|
27 |
root |
1.6 |
# when you also use Coro, management is easy: |
28 |
|
|
use Coro::BDB; |
29 |
|
|
|
30 |
root |
1.16 |
# automatic event loop integration with AnyEvent: |
31 |
root |
1.9 |
use AnyEvent::BDB; |
32 |
root |
1.4 |
|
33 |
|
|
# automatic result processing with EV: |
34 |
|
|
my $WATCHER = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb; |
35 |
|
|
|
36 |
|
|
# with Glib: |
37 |
|
|
add_watch Glib::IO BDB::poll_fileno, |
38 |
|
|
in => sub { BDB::poll_cb; 1 }; |
39 |
|
|
|
40 |
|
|
# or simply flush manually |
41 |
|
|
BDB::flush; |
42 |
|
|
|
43 |
root |
1.3 |
DESCRIPTION |
44 |
|
|
See the BerkeleyDB documentation |
45 |
|
|
(<http://www.oracle.com/technology/documentation/berkeley-db/db/index.ht |
46 |
|
|
ml>). The BDB API is very similar to the C API (the translation has been |
47 |
|
|
very faithful). |
48 |
|
|
|
49 |
|
|
See also the example sections in the document below and possibly the eg/ |
50 |
|
|
subdirectory of the BDB distribution. Last not least see the IO::AIO |
51 |
|
|
documentation, as that module uses almost the same asynchronous request |
52 |
|
|
model as this module. |
53 |
|
|
|
54 |
|
|
I know this is woefully inadequate documentation. Send a patch! |
55 |
|
|
|
56 |
|
|
REQUEST ANATOMY AND LIFETIME |
57 |
|
|
Every request method creates a request. which is a C data structure not |
58 |
|
|
directly visible to Perl. |
59 |
|
|
|
60 |
|
|
During their existance, bdb requests travel through the following |
61 |
|
|
states, in order: |
62 |
|
|
|
63 |
|
|
ready |
64 |
|
|
Immediately after a request is created it is put into the ready |
65 |
|
|
state, waiting for a thread to execute it. |
66 |
|
|
|
67 |
|
|
execute |
68 |
|
|
A thread has accepted the request for processing and is currently |
69 |
|
|
executing it (e.g. blocking in read). |
70 |
|
|
|
71 |
|
|
pending |
72 |
|
|
The request has been executed and is waiting for result processing. |
73 |
|
|
|
74 |
|
|
While request submission and execution is fully asynchronous, result |
75 |
|
|
processing is not and relies on the perl interpreter calling |
76 |
|
|
"poll_cb" (or another function with the same effect). |
77 |
|
|
|
78 |
|
|
result |
79 |
|
|
The request results are processed synchronously by "poll_cb". |
80 |
|
|
|
81 |
|
|
The "poll_cb" function will process all outstanding aio requests by |
82 |
|
|
calling their callbacks, freeing memory associated with them and |
83 |
|
|
managing any groups they are contained in. |
84 |
|
|
|
85 |
|
|
done |
86 |
|
|
Request has reached the end of its lifetime and holds no resources |
87 |
|
|
anymore (except possibly for the Perl object, but its connection to |
88 |
|
|
the actual aio request is severed and calling its methods will |
89 |
|
|
either do nothing or result in a runtime error). |
90 |
|
|
|
91 |
root |
1.14 |
BERKELEYDB FUNCTIONS |
92 |
root |
1.3 |
All of these are functions. The create functions simply return a new |
93 |
root |
1.7 |
object and never block. All the remaining functions take an optional |
94 |
root |
1.5 |
callback as last argument. If it is missing, then the function will be |
95 |
|
|
executed synchronously. In both cases, $! will reflect the return value |
96 |
|
|
of the function. |
97 |
root |
1.3 |
|
98 |
|
|
BDB functions that cannot block (mostly functions that manipulate |
99 |
|
|
settings) are method calls on the relevant objects, so the rule of thumb |
100 |
root |
1.7 |
is: if it's a method, it's not blocking, if it's a function, it takes a |
101 |
root |
1.3 |
callback as last argument. |
102 |
|
|
|
103 |
root |
1.10 |
In the following, $int signifies an integer return value, "bdb_filename" |
104 |
|
|
is a "filename" (octets on unix, madness on windows), "U32" is an |
105 |
|
|
unsigned 32 bit integer, "int" is some integer, "NV" is a floating point |
106 |
|
|
value. |
107 |
root |
1.3 |
|
108 |
root |
1.11 |
Most "SV *" types are generic perl scalars (for input and output of data |
109 |
|
|
values). |
110 |
root |
1.3 |
|
111 |
|
|
The various "DB_ENV" etc. arguments are handles return by |
112 |
|
|
"db_env_create", "db_create", "txn_begin" and so on. If they have an |
113 |
|
|
appended "_ornull" this means they are optional and you can pass "undef" |
114 |
|
|
for them, resulting a NULL pointer on the C level. |
115 |
|
|
|
116 |
root |
1.11 |
The "SV *callback" is the optional callback function to call when the |
117 |
|
|
request is completed. This last callback argument is special: the |
118 |
|
|
callback is simply the last argument passed. If there are "optional" |
119 |
|
|
arguments before the callback they can be left out. The callback itself |
120 |
|
|
can be left out or specified as "undef", in which case the function will |
121 |
|
|
be executed synchronously. |
122 |
|
|
|
123 |
|
|
For example, "db_env_txn_checkpoint" usually is called with all integer |
124 |
|
|
arguments zero. These can be left out, so all of these specify a call to |
125 |
|
|
"DB_ENV->txn_checkpoint", to be executed asynchronously with a callback |
126 |
|
|
to be called: |
127 |
|
|
|
128 |
|
|
db_env_txn_checkpoint $db_env, 0, 0, 0, sub { }; |
129 |
|
|
db_env_txn_checkpoint $db_env, 0, 0, sub { }; |
130 |
|
|
db_env_txn_checkpoint $db_env, sub { }; |
131 |
|
|
|
132 |
|
|
While these all specify a call to "DB_ENV->txn_checkpoint" to be |
133 |
|
|
executed synchronously: |
134 |
|
|
|
135 |
|
|
db_env_txn_checkpoint $db_env, 0, 0, 0, undef; |
136 |
|
|
db_env_txn_checkpoint $db_env, 0, 0, 0; |
137 |
|
|
db_env_txn_checkpoint $db_env, 0; |
138 |
|
|
|
139 |
root |
1.14 |
BDB functions |
140 |
root |
1.3 |
Functions in the BDB namespace, exported by default: |
141 |
|
|
|
142 |
|
|
$env = db_env_create (U32 env_flags = 0) |
143 |
|
|
flags: RPCCLIENT |
144 |
|
|
|
145 |
root |
1.15 |
db_env_open (DB_ENV *env, bdb_filename db_home, U32 open_flags, int mode, SV *callback = 0) |
146 |
root |
1.3 |
open_flags: INIT_CDB INIT_LOCK INIT_LOG INIT_MPOOL INIT_REP INIT_TXN RECOVER RECOVER_FATAL USE_ENVIRON USE_ENVIRON_ROOT CREATE LOCKDOWN PRIVATE REGISTER SYSTEM_MEM |
147 |
root |
1.15 |
db_env_close (DB_ENV *env, U32 flags = 0, SV *callback = 0) |
148 |
|
|
db_env_txn_checkpoint (DB_ENV *env, U32 kbyte = 0, U32 min = 0, U32 flags = 0, SV *callback = 0) |
149 |
root |
1.3 |
flags: FORCE |
150 |
root |
1.15 |
db_env_lock_detect (DB_ENV *env, U32 flags = 0, U32 atype = DB_LOCK_DEFAULT, SV *dummy = 0, SV *callback = 0) |
151 |
root |
1.3 |
atype: LOCK_DEFAULT LOCK_EXPIRE LOCK_MAXLOCKS LOCK_MAXWRITE LOCK_MINLOCKS LOCK_MINWRITE LOCK_OLDEST LOCK_RANDOM LOCK_YOUNGEST |
152 |
root |
1.15 |
db_env_memp_sync (DB_ENV *env, SV *dummy = 0, SV *callback = 0) |
153 |
|
|
db_env_memp_trickle (DB_ENV *env, int percent, SV *dummy = 0, SV *callback = 0) |
154 |
|
|
db_env_dbremove (DB_ENV *env, DB_TXN_ornull *txnid, bdb_filename file, bdb_filename database, U32 flags = 0, SV *callback = 0) |
155 |
|
|
db_env_dbrename (DB_ENV *env, DB_TXN_ornull *txnid, bdb_filename file, bdb_filename database, bdb_filename newname, U32 flags = 0, SV *callback = 0) |
156 |
|
|
db_env_log_archive (DB_ENV *env, SV *listp, U32 flags = 0, SV *callback = 0) |
157 |
root |
1.3 |
|
158 |
|
|
$db = db_create (DB_ENV *env = 0, U32 flags = 0) |
159 |
|
|
flags: XA_CREATE |
160 |
|
|
|
161 |
root |
1.15 |
db_open (DB *db, DB_TXN_ornull *txnid, bdb_filename file, bdb_filename database, int type, U32 flags, int mode, SV *callback = 0) |
162 |
root |
1.3 |
flags: AUTO_COMMIT CREATE EXCL MULTIVERSION NOMMAP RDONLY READ_UNCOMMITTED THREAD TRUNCATE |
163 |
root |
1.15 |
db_close (DB *db, U32 flags = 0, SV *callback = 0) |
164 |
root |
1.3 |
flags: DB_NOSYNC |
165 |
root |
1.15 |
db_verify (DB *db, bdb_filename file, bdb_filename database = 0, SV *dummy = 0, U32 flags = 0, SV *callback = 0) |
166 |
|
|
db_upgrade (DB *db, bdb_filename file, U32 flags = 0, SV *callback = 0) |
167 |
|
|
db_compact (DB *db, DB_TXN_ornull *txn = 0, SV *start = 0, SV *stop = 0, SV *unused1 = 0, U32 flags = DB_FREE_SPACE, SV *unused2 = 0, SV *callback = 0) |
168 |
root |
1.3 |
flags: FREELIST_ONLY FREE_SPACE |
169 |
root |
1.15 |
db_sync (DB *db, U32 flags = 0, SV *callback = 0) |
170 |
|
|
db_key_range (DB *db, DB_TXN_ornull *txn, SV *key, SV *key_range, U32 flags = 0, SV *callback = 0) |
171 |
|
|
db_put (DB *db, DB_TXN_ornull *txn, SV *key, SV *data, U32 flags = 0, SV *callback = 0) |
172 |
root |
1.3 |
flags: APPEND NODUPDATA NOOVERWRITE |
173 |
root |
1.11 |
db_exists (DB *db, DB_TXN_ornull *txn, SV *key, U32 flags = 0, SV *callback = 0) (v4.6) |
174 |
root |
1.15 |
db_get (DB *db, DB_TXN_ornull *txn, SV *key, SV *data, U32 flags = 0, SV *callback = 0) |
175 |
root |
1.3 |
flags: CONSUME CONSUME_WAIT GET_BOTH SET_RECNO MULTIPLE READ_COMMITTED READ_UNCOMMITTED RMW |
176 |
root |
1.15 |
db_pget (DB *db, DB_TXN_ornull *txn, SV *key, SV *pkey, SV *data, U32 flags = 0, SV *callback = 0) |
177 |
root |
1.3 |
flags: CONSUME CONSUME_WAIT GET_BOTH SET_RECNO MULTIPLE READ_COMMITTED READ_UNCOMMITTED RMW |
178 |
root |
1.15 |
db_del (DB *db, DB_TXN_ornull *txn, SV *key, U32 flags = 0, SV *callback = 0) |
179 |
|
|
db_txn_commit (DB_TXN *txn, U32 flags = 0, SV *callback = 0) |
180 |
root |
1.3 |
flags: TXN_NOSYNC TXN_SYNC |
181 |
root |
1.15 |
db_txn_abort (DB_TXN *txn, SV *callback = 0) |
182 |
root |
1.3 |
|
183 |
root |
1.15 |
db_c_close (DBC *dbc, SV *callback = 0) |
184 |
|
|
db_c_count (DBC *dbc, SV *count, U32 flags = 0, SV *callback = 0) |
185 |
|
|
db_c_put (DBC *dbc, SV *key, SV *data, U32 flags = 0, SV *callback = 0) |
186 |
root |
1.3 |
flags: AFTER BEFORE CURRENT KEYFIRST KEYLAST NODUPDATA |
187 |
root |
1.15 |
db_c_get (DBC *dbc, SV *key, SV *data, U32 flags = 0, SV *callback = 0) |
188 |
root |
1.3 |
flags: CURRENT FIRST GET_BOTH GET_BOTH_RANGE GET_RECNO JOIN_ITEM LAST NEXT NEXT_DUP NEXT_NODUP PREV PREV_DUP PREV_NODUP SET SET_RANGE SET_RECNO READ_UNCOMMITTED MULTIPLE MULTIPLE_KEY RMW |
189 |
root |
1.15 |
db_c_pget (DBC *dbc, SV *key, SV *pkey, SV *data, U32 flags = 0, SV *callback = 0) |
190 |
|
|
db_c_del (DBC *dbc, U32 flags = 0, SV *callback = 0) |
191 |
root |
1.3 |
|
192 |
root |
1.15 |
db_sequence_open (DB_SEQUENCE *seq, DB_TXN_ornull *txnid, SV *key, U32 flags = 0, SV *callback = 0) |
193 |
root |
1.3 |
flags: CREATE EXCL |
194 |
root |
1.15 |
db_sequence_close (DB_SEQUENCE *seq, U32 flags = 0, SV *callback = 0) |
195 |
|
|
db_sequence_get (DB_SEQUENCE *seq, DB_TXN_ornull *txnid, int delta, SV *seq_value, U32 flags = DB_TXN_NOSYNC, SV *callback = 0) |
196 |
root |
1.3 |
flags: TXN_NOSYNC |
197 |
root |
1.15 |
db_sequence_remove (DB_SEQUENCE *seq, DB_TXN_ornull *txnid = 0, U32 flags = 0, SV *callback = 0) |
198 |
root |
1.3 |
flags: TXN_NOSYNC |
199 |
|
|
|
200 |
root |
1.15 |
db_txn_finish (DB_TXN *txn, U32 flags = 0, SV *callback = 0) |
201 |
root |
1.3 |
This is not actually a Berkeley DB function but a BDB module extension. |
202 |
|
|
The background for this exytension is: It is very annoying to have to |
203 |
|
|
check every single BDB function for error returns and provide a codepath |
204 |
|
|
out of your transaction. While the BDB module still makes this possible, |
205 |
|
|
it contains the following extensions: |
206 |
|
|
|
207 |
|
|
When a transaction-protected function returns any operating system error |
208 |
|
|
(errno > 0), BDB will set the "TXN_DEADLOCK" flag on the transaction. |
209 |
|
|
This flag is also set by Berkeley DB functions themselves when an |
210 |
|
|
operation fails with LOCK_DEADLOCK, and it causes all further operations |
211 |
|
|
on that transaction (including "db_txn_commit") to fail. |
212 |
|
|
|
213 |
|
|
The "db_txn_finish" request will look at this flag, and, if it is set, |
214 |
|
|
will automatically call "db_txn_abort" (setting errno to "LOCK_DEADLOCK" |
215 |
|
|
if it isn't set to something else yet). If it isn't set, it will call |
216 |
|
|
"db_txn_commit" and return the error normally. |
217 |
|
|
|
218 |
|
|
How to use this? Easy: just write your transaction normally: |
219 |
|
|
|
220 |
|
|
my $txn = $db_env->txn_begin; |
221 |
|
|
db_get $db, $txn, "key", my $data; |
222 |
|
|
db_put $db, $txn, "key", $data + 1 unless $! == BDB::NOTFOUND; |
223 |
|
|
db_txn_finish $txn; |
224 |
|
|
die "transaction failed" if $!; |
225 |
|
|
|
226 |
|
|
That is, handle only the expected errors. If something unexpected |
227 |
|
|
happens (EIO, LOCK_NOTGRANTED or a deadlock in either db_get or db_put), |
228 |
|
|
then the remaining requests (db_put in this case) will simply be skipped |
229 |
|
|
(they will fail with LOCK_DEADLOCK) and the transaction will be aborted. |
230 |
|
|
|
231 |
|
|
You can use the "$txn->failed" method to check wether a transaction has |
232 |
|
|
failed in this way and abort further processing (excluding |
233 |
|
|
"db_txn_finish"). |
234 |
|
|
|
235 |
root |
1.14 |
DB_ENV/database environment methods |
236 |
root |
1.3 |
Methods available on DB_ENV/$env handles: |
237 |
|
|
|
238 |
|
|
DESTROY (DB_ENV_ornull *env) |
239 |
|
|
CODE: |
240 |
|
|
if (env) |
241 |
|
|
env->close (env, 0); |
242 |
|
|
|
243 |
|
|
$int = $env->set_data_dir (const char *dir) |
244 |
|
|
$int = $env->set_tmp_dir (const char *dir) |
245 |
|
|
$int = $env->set_lg_dir (const char *dir) |
246 |
|
|
$int = $env->set_shm_key (long shm_key) |
247 |
|
|
$int = $env->set_cachesize (U32 gbytes, U32 bytes, int ncache = 0) |
248 |
root |
1.10 |
$int = $env->set_flags (U32 flags, int onoff = 1) |
249 |
root |
1.11 |
$int = $env->log_set_config (U32 flags, int onoff = 1) (v4.7) |
250 |
|
|
$int = $env->set_intermediate_dir_mode (const char *modestring) (v4.7) |
251 |
root |
1.3 |
$env->set_errfile (FILE *errfile = 0) |
252 |
|
|
$env->set_msgfile (FILE *msgfile = 0) |
253 |
|
|
$int = $env->set_verbose (U32 which, int onoff = 1) |
254 |
|
|
$int = $env->set_encrypt (const char *password, U32 flags = 0) |
255 |
|
|
$int = $env->set_timeout (NV timeout_seconds, U32 flags = SET_TXN_TIMEOUT) |
256 |
|
|
$int = $env->set_mp_max_openfd (int maxopenfd); |
257 |
|
|
$int = $env->set_mp_max_write (int maxwrite, int maxwrite_sleep); |
258 |
|
|
$int = $env->set_mp_mmapsize (int mmapsize_mb) |
259 |
|
|
$int = $env->set_lk_detect (U32 detect = DB_LOCK_DEFAULT) |
260 |
|
|
$int = $env->set_lk_max_lockers (U32 max) |
261 |
|
|
$int = $env->set_lk_max_locks (U32 max) |
262 |
|
|
$int = $env->set_lk_max_objects (U32 max) |
263 |
|
|
$int = $env->set_lg_bsize (U32 max) |
264 |
|
|
$int = $env->set_lg_max (U32 max) |
265 |
root |
1.4 |
$int = $env->mutex_set_increment (U32 increment) |
266 |
|
|
$int = $env->mutex_set_tas_spins (U32 tas_spins) |
267 |
|
|
$int = $env->mutex_set_max (U32 max) |
268 |
|
|
$int = $env->mutex_set_align (U32 align) |
269 |
root |
1.3 |
|
270 |
|
|
$txn = $env->txn_begin (DB_TXN_ornull *parent = 0, U32 flags = 0) |
271 |
|
|
flags: READ_COMMITTED READ_UNCOMMITTED TXN_NOSYNC TXN_NOWAIT TXN_SNAPSHOT TXN_SYNC TXN_WAIT TXN_WRITE_NOSYNC |
272 |
root |
1.11 |
$txn = $env->cdsgroup_begin; (v4.5) |
273 |
root |
1.3 |
|
274 |
|
|
Example: |
275 |
|
|
use AnyEvent; |
276 |
|
|
use BDB; |
277 |
|
|
|
278 |
|
|
our $FH; open $FH, "<&=" . BDB::poll_fileno; |
279 |
|
|
our $WATCHER = AnyEvent->io (fh => $FH, poll => 'r', cb => \&BDB::poll_cb); |
280 |
|
|
|
281 |
|
|
BDB::min_parallel 8; |
282 |
|
|
|
283 |
|
|
my $env = db_env_create; |
284 |
|
|
|
285 |
|
|
mkdir "bdtest", 0700; |
286 |
|
|
db_env_open |
287 |
|
|
$env, |
288 |
|
|
"bdtest", |
289 |
|
|
BDB::INIT_LOCK | BDB::INIT_LOG | BDB::INIT_MPOOL | BDB::INIT_TXN | BDB::RECOVER | BDB::USE_ENVIRON | BDB::CREATE, |
290 |
|
|
0600; |
291 |
|
|
|
292 |
|
|
$env->set_flags (BDB::AUTO_COMMIT | BDB::TXN_NOSYNC, 1); |
293 |
|
|
|
294 |
root |
1.14 |
DB/database methods |
295 |
root |
1.3 |
Methods available on DB/$db handles: |
296 |
|
|
|
297 |
|
|
DESTROY (DB_ornull *db) |
298 |
|
|
CODE: |
299 |
|
|
if (db) |
300 |
|
|
{ |
301 |
|
|
SV *env = (SV *)db->app_private; |
302 |
|
|
db->close (db, 0); |
303 |
|
|
SvREFCNT_dec (env); |
304 |
|
|
} |
305 |
|
|
|
306 |
|
|
$int = $db->set_cachesize (U32 gbytes, U32 bytes, int ncache = 0) |
307 |
|
|
$int = $db->set_flags (U32 flags) |
308 |
|
|
flags: CHKSUM ENCRYPT TXN_NOT_DURABLE |
309 |
|
|
Btree: DUP DUPSORT RECNUM REVSPLITOFF |
310 |
|
|
Hash: DUP DUPSORT |
311 |
|
|
Queue: INORDER |
312 |
|
|
Recno: RENUMBER SNAPSHOT |
313 |
|
|
|
314 |
|
|
$int = $db->set_encrypt (const char *password, U32 flags) |
315 |
|
|
$int = $db->set_lorder (int lorder) |
316 |
|
|
$int = $db->set_bt_minkey (U32 minkey) |
317 |
|
|
$int = $db->set_re_delim (int delim) |
318 |
|
|
$int = $db->set_re_pad (int re_pad) |
319 |
|
|
$int = $db->set_re_source (char *source) |
320 |
|
|
$int = $db->set_re_len (U32 re_len) |
321 |
|
|
$int = $db->set_h_ffactor (U32 h_ffactor) |
322 |
|
|
$int = $db->set_h_nelem (U32 h_nelem) |
323 |
|
|
$int = $db->set_q_extentsize (U32 extentsize) |
324 |
|
|
|
325 |
|
|
$dbc = $db->cursor (DB_TXN_ornull *txn = 0, U32 flags = 0) |
326 |
|
|
flags: READ_COMMITTED READ_UNCOMMITTED WRITECURSOR TXN_SNAPSHOT |
327 |
|
|
$seq = $db->sequence (U32 flags = 0) |
328 |
|
|
|
329 |
|
|
Example: |
330 |
|
|
my $db = db_create $env; |
331 |
|
|
db_open $db, undef, "table", undef, BDB::BTREE, BDB::AUTO_COMMIT | BDB::CREATE | BDB::READ_UNCOMMITTED, 0600; |
332 |
|
|
|
333 |
|
|
for (1..1000) { |
334 |
|
|
db_put $db, undef, "key $_", "data $_"; |
335 |
|
|
|
336 |
|
|
db_key_range $db, undef, "key $_", my $keyrange; |
337 |
|
|
my ($lt, $eq, $gt) = @$keyrange; |
338 |
|
|
} |
339 |
|
|
|
340 |
|
|
db_del $db, undef, "key $_" for 1..1000; |
341 |
|
|
|
342 |
|
|
db_sync $db; |
343 |
|
|
|
344 |
root |
1.14 |
DB_TXN/transaction methods |
345 |
root |
1.3 |
Methods available on DB_TXN/$txn handles: |
346 |
|
|
|
347 |
|
|
DESTROY (DB_TXN_ornull *txn) |
348 |
|
|
CODE: |
349 |
|
|
if (txn) |
350 |
|
|
txn->abort (txn); |
351 |
|
|
|
352 |
|
|
$int = $txn->set_timeout (NV timeout_seconds, U32 flags = SET_TXN_TIMEOUT) |
353 |
|
|
flags: SET_LOCK_TIMEOUT SET_TXN_TIMEOUT |
354 |
|
|
|
355 |
|
|
$bool = $txn->failed |
356 |
|
|
# see db_txn_finish documentation, above |
357 |
|
|
|
358 |
root |
1.14 |
DBC/cursor methods |
359 |
root |
1.3 |
Methods available on DBC/$dbc handles: |
360 |
|
|
|
361 |
|
|
DESTROY (DBC_ornull *dbc) |
362 |
|
|
CODE: |
363 |
|
|
if (dbc) |
364 |
|
|
dbc->c_close (dbc); |
365 |
|
|
|
366 |
root |
1.11 |
$int = $cursor->set_priority ($priority = PRIORITY_*) (v4.6) |
367 |
root |
1.6 |
|
368 |
root |
1.3 |
Example: |
369 |
|
|
my $c = $db->cursor; |
370 |
|
|
|
371 |
|
|
for (;;) { |
372 |
|
|
db_c_get $c, my $key, my $data, BDB::NEXT; |
373 |
|
|
warn "<$!,$key,$data>"; |
374 |
|
|
last if $!; |
375 |
|
|
} |
376 |
|
|
|
377 |
|
|
db_c_close $c; |
378 |
|
|
|
379 |
root |
1.14 |
DB_SEQUENCE/sequence methods |
380 |
root |
1.3 |
Methods available on DB_SEQUENCE/$seq handles: |
381 |
|
|
|
382 |
|
|
DESTROY (DB_SEQUENCE_ornull *seq) |
383 |
|
|
CODE: |
384 |
|
|
if (seq) |
385 |
|
|
seq->close (seq, 0); |
386 |
|
|
|
387 |
|
|
$int = $seq->initial_value (db_seq_t value) |
388 |
|
|
$int = $seq->set_cachesize (U32 size) |
389 |
|
|
$int = $seq->set_flags (U32 flags) |
390 |
|
|
flags: SEQ_DEC SEQ_INC SEQ_WRAP |
391 |
|
|
$int = $seq->set_range (db_seq_t min, db_seq_t max) |
392 |
|
|
|
393 |
|
|
Example: |
394 |
|
|
my $seq = $db->sequence; |
395 |
root |
1.16 |
|
396 |
|
|
db_sequence_open $seq, undef, "seq", BDB::CREATE; |
397 |
root |
1.3 |
db_sequence_get $seq, undef, 1, my $value; |
398 |
|
|
|
399 |
root |
1.14 |
SUPPORT FUNCTIONS |
400 |
|
|
EVENT PROCESSING AND EVENT LOOP INTEGRATION |
401 |
root |
1.5 |
$msg = BDB::strerror [$errno] |
402 |
|
|
Returns the string corresponding to the given errno value. If no |
403 |
|
|
argument is given, use $!. |
404 |
|
|
|
405 |
root |
1.7 |
Note that the BDB module also patches the $! variable directly, so |
406 |
|
|
you should be able to get a bdb error string by simply stringifying |
407 |
|
|
$!. |
408 |
|
|
|
409 |
root |
1.3 |
$fileno = BDB::poll_fileno |
410 |
|
|
Return the *request result pipe file descriptor*. This filehandle |
411 |
|
|
must be polled for reading by some mechanism outside this module |
412 |
|
|
(e.g. Event or select, see below or the SYNOPSIS). If the pipe |
413 |
|
|
becomes readable you have to call "poll_cb" to check the results. |
414 |
|
|
|
415 |
|
|
See "poll_cb" for an example. |
416 |
|
|
|
417 |
|
|
BDB::poll_cb |
418 |
|
|
Process some outstanding events on the result pipe. You have to call |
419 |
|
|
this regularly. Returns the number of events processed. Returns |
420 |
|
|
immediately when no events are outstanding. The amount of events |
421 |
|
|
processed depends on the settings of "BDB::max_poll_req" and |
422 |
|
|
"BDB::max_poll_time". |
423 |
|
|
|
424 |
|
|
If not all requests were processed for whatever reason, the |
425 |
|
|
filehandle will still be ready when "poll_cb" returns. |
426 |
|
|
|
427 |
|
|
Example: Install an Event watcher that automatically calls |
428 |
|
|
BDB::poll_cb with high priority: |
429 |
|
|
|
430 |
|
|
Event->io (fd => BDB::poll_fileno, |
431 |
|
|
poll => 'r', async => 1, |
432 |
|
|
cb => \&BDB::poll_cb); |
433 |
|
|
|
434 |
|
|
BDB::max_poll_reqs $nreqs |
435 |
|
|
BDB::max_poll_time $seconds |
436 |
|
|
These set the maximum number of requests (default 0, meaning |
437 |
|
|
infinity) that are being processed by "BDB::poll_cb" in one call, |
438 |
|
|
respectively the maximum amount of time (default 0, meaning |
439 |
|
|
infinity) spent in "BDB::poll_cb" to process requests (more |
440 |
|
|
correctly the mininum amount of time "poll_cb" is allowed to use). |
441 |
|
|
|
442 |
|
|
Setting "max_poll_time" to a non-zero value creates an overhead of |
443 |
|
|
one syscall per request processed, which is not normally a problem |
444 |
|
|
unless your callbacks are really really fast or your OS is really |
445 |
|
|
really slow (I am not mentioning Solaris here). Using |
446 |
|
|
"max_poll_reqs" incurs no overhead. |
447 |
|
|
|
448 |
|
|
Setting these is useful if you want to ensure some level of |
449 |
|
|
interactiveness when perl is not fast enough to process all requests |
450 |
|
|
in time. |
451 |
|
|
|
452 |
|
|
For interactive programs, values such as 0.01 to 0.1 should be fine. |
453 |
|
|
|
454 |
root |
1.4 |
Example: Install an EV watcher that automatically calls BDB::poll_cb |
455 |
|
|
with low priority, to ensure that other parts of the program get the |
456 |
|
|
CPU sometimes even under high load. |
457 |
root |
1.3 |
|
458 |
|
|
# try not to spend much more than 0.1s in poll_cb |
459 |
|
|
BDB::max_poll_time 0.1; |
460 |
|
|
|
461 |
root |
1.4 |
my $bdb_poll = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb); |
462 |
root |
1.3 |
|
463 |
|
|
BDB::poll_wait |
464 |
|
|
If there are any outstanding requests and none of them in the result |
465 |
|
|
phase, wait till the result filehandle becomes ready for reading |
466 |
|
|
(simply does a "select" on the filehandle. This is useful if you |
467 |
|
|
want to synchronously wait for some requests to finish). |
468 |
|
|
|
469 |
|
|
See "nreqs" for an example. |
470 |
|
|
|
471 |
|
|
BDB::poll |
472 |
|
|
Waits until some requests have been handled. |
473 |
|
|
|
474 |
|
|
Returns the number of requests processed, but is otherwise strictly |
475 |
|
|
equivalent to: |
476 |
|
|
|
477 |
|
|
BDB::poll_wait, BDB::poll_cb |
478 |
|
|
|
479 |
|
|
BDB::flush |
480 |
root |
1.4 |
Wait till all outstanding BDB requests have been handled. |
481 |
root |
1.3 |
|
482 |
|
|
Strictly equivalent to: |
483 |
|
|
|
484 |
|
|
BDB::poll_wait, BDB::poll_cb |
485 |
|
|
while BDB::nreqs; |
486 |
|
|
|
487 |
root |
1.14 |
VERSION CHECKING |
488 |
root |
1.10 |
BerkeleyDB comes in various versions, many of them have minor |
489 |
|
|
incompatibilities. This means that traditional "at least version x.x" |
490 |
|
|
checks are often not sufficient. |
491 |
|
|
|
492 |
root |
1.12 |
Example: set the log_autoremove option in a way compatible with <v4.7 |
493 |
root |
1.10 |
and v4.7. Note the use of & on the constants to avoid triggering a |
494 |
|
|
compiletime bug when the symbol isn't available. |
495 |
|
|
|
496 |
|
|
$DB_ENV->set_flags (&BDB::LOG_AUTOREMOVE ) if BDB::VERSION v0, v4.7; |
497 |
|
|
$DB_ENV->log_set_config (&BDB::LOG_AUTO_REMOVE) if BDB::VERSION v4.7; |
498 |
|
|
|
499 |
|
|
BDB::VERSION |
500 |
|
|
The "BDB::VERSION" function, when called without arguments, returns |
501 |
|
|
the Berkeley DB version as a v-string (usually with 3 components). |
502 |
|
|
You should use "lt" and "ge" operators exclusively to make |
503 |
|
|
comparisons. |
504 |
|
|
|
505 |
|
|
Example: check for at least version 4.7. |
506 |
|
|
|
507 |
|
|
BDB::VERSION ge v4.7 or die; |
508 |
|
|
|
509 |
|
|
BDB::VERSION min-version |
510 |
|
|
Returns true if the BDB version is at least the given version |
511 |
|
|
(specified as a v-string), false otherwise. |
512 |
|
|
|
513 |
|
|
Example: check for at least version 4.5. |
514 |
|
|
|
515 |
|
|
BDB::VERSION v4.7 or die; |
516 |
|
|
|
517 |
|
|
BDB::VERSION min-version, max-version |
518 |
|
|
Returns true of the BDB version is at least version "min-version" |
519 |
|
|
(specify "undef" or "v0" for any minimum version) and less then |
520 |
|
|
"max-version". |
521 |
|
|
|
522 |
|
|
Example: check wether version is strictly less then v4.7. |
523 |
|
|
|
524 |
|
|
BDB::VERSION v0, v4.7 |
525 |
|
|
or die "version 4.7 is not yet supported"; |
526 |
|
|
|
527 |
root |
1.14 |
CONTROLLING THE NUMBER OF THREADS |
528 |
root |
1.3 |
BDB::min_parallel $nthreads |
529 |
root |
1.4 |
Set the minimum number of BDB threads to $nthreads. The current |
530 |
root |
1.3 |
default is 8, which means eight asynchronous operations can execute |
531 |
|
|
concurrently at any one time (the number of outstanding requests, |
532 |
|
|
however, is unlimited). |
533 |
|
|
|
534 |
root |
1.4 |
BDB starts threads only on demand, when an BDB request is queued and |
535 |
root |
1.3 |
no free thread exists. Please note that queueing up a hundred |
536 |
|
|
requests can create demand for a hundred threads, even if it turns |
537 |
|
|
out that everything is in the cache and could have been processed |
538 |
|
|
faster by a single thread. |
539 |
|
|
|
540 |
|
|
It is recommended to keep the number of threads relatively low, as |
541 |
|
|
some Linux kernel versions will scale negatively with the number of |
542 |
|
|
threads (higher parallelity => MUCH higher latency). With current |
543 |
|
|
Linux 2.6 versions, 4-32 threads should be fine. |
544 |
|
|
|
545 |
|
|
Under most circumstances you don't need to call this function, as |
546 |
|
|
the module selects a default that is suitable for low to moderate |
547 |
|
|
load. |
548 |
|
|
|
549 |
|
|
BDB::max_parallel $nthreads |
550 |
root |
1.4 |
Sets the maximum number of BDB threads to $nthreads. If more than |
551 |
root |
1.3 |
the specified number of threads are currently running, this function |
552 |
|
|
kills them. This function blocks until the limit is reached. |
553 |
|
|
|
554 |
|
|
While $nthreads are zero, aio requests get queued but not executed |
555 |
|
|
until the number of threads has been increased again. |
556 |
|
|
|
557 |
|
|
This module automatically runs "max_parallel 0" at program end, to |
558 |
|
|
ensure that all threads are killed and that there are no outstanding |
559 |
|
|
requests. |
560 |
|
|
|
561 |
|
|
Under normal circumstances you don't need to call this function. |
562 |
|
|
|
563 |
|
|
BDB::max_idle $nthreads |
564 |
|
|
Limit the number of threads (default: 4) that are allowed to idle |
565 |
|
|
(i.e., threads that did not get a request to process within 10 |
566 |
|
|
seconds). That means if a thread becomes idle while $nthreads other |
567 |
|
|
threads are also idle, it will free its resources and exit. |
568 |
|
|
|
569 |
|
|
This is useful when you allow a large number of threads (e.g. 100 or |
570 |
|
|
1000) to allow for extremely high load situations, but want to free |
571 |
|
|
resources under normal circumstances (1000 threads can easily |
572 |
|
|
consume 30MB of RAM). |
573 |
|
|
|
574 |
|
|
The default is probably ok in most situations, especially if thread |
575 |
|
|
creation is fast. If thread creation is very slow on your system you |
576 |
|
|
might want to use larger values. |
577 |
|
|
|
578 |
|
|
$oldmaxreqs = BDB::max_outstanding $maxreqs |
579 |
|
|
This is a very bad function to use in interactive programs because |
580 |
|
|
it blocks, and a bad way to reduce concurrency because it is |
581 |
|
|
inexact: Better use an "aio_group" together with a feed callback. |
582 |
|
|
|
583 |
|
|
Sets the maximum number of outstanding requests to $nreqs. If you to |
584 |
|
|
queue up more than this number of requests, the next call to the |
585 |
|
|
"poll_cb" (and "poll_some" and other functions calling "poll_cb") |
586 |
|
|
function will block until the limit is no longer exceeded. |
587 |
|
|
|
588 |
|
|
The default value is very large, so there is no practical limit on |
589 |
|
|
the number of outstanding requests. |
590 |
|
|
|
591 |
|
|
You can still queue as many requests as you want. Therefore, |
592 |
|
|
"max_oustsanding" is mainly useful in simple scripts (with low |
593 |
|
|
values) or as a stop gap to shield against fatal memory overflow |
594 |
|
|
(with large values). |
595 |
|
|
|
596 |
root |
1.13 |
$old_cb = BDB::set_sync_prepare $cb |
597 |
root |
1.3 |
Sets a callback that is called whenever a request is created without |
598 |
|
|
an explicit callback. It has to return two code references. The |
599 |
root |
1.10 |
first is used as the request callback (it should save the return |
600 |
|
|
status), and the second is called to wait until the first callback |
601 |
|
|
has been called (it must set $! to the return status). |
602 |
|
|
|
603 |
|
|
This mechanism can be used to include BDB into other event |
604 |
root |
1.13 |
mechanisms, such as Coro::BDB. |
605 |
root |
1.10 |
|
606 |
root |
1.13 |
To allow other, callback-based, events to be executed while |
607 |
|
|
callback-less ones are run, you could use this sync prepare |
608 |
|
|
function: |
609 |
root |
1.3 |
|
610 |
|
|
sub { |
611 |
|
|
my $status; |
612 |
|
|
( |
613 |
|
|
sub { $status = $! }, |
614 |
|
|
sub { BDB::poll while !defined $status; $! = $status }, |
615 |
|
|
) |
616 |
|
|
} |
617 |
|
|
|
618 |
root |
1.13 |
It works by polling for results till the request has finished and |
619 |
|
|
then sets $! to the return value. This means that if you don't use a |
620 |
|
|
callback, BDB would simply fall back to synchronous operations. |
621 |
|
|
|
622 |
|
|
By default, or if the sync prepare function is set to "undef", is to |
623 |
|
|
execute callback-less BDB requests in the foreground thread, setting |
624 |
|
|
$! to the return value, without polling for other events. |
625 |
root |
1.10 |
|
626 |
root |
1.14 |
STATISTICAL INFORMATION |
627 |
root |
1.3 |
BDB::nreqs |
628 |
|
|
Returns the number of requests currently in the ready, execute or |
629 |
|
|
pending states (i.e. for which their callback has not been invoked |
630 |
|
|
yet). |
631 |
|
|
|
632 |
|
|
Example: wait till there are no outstanding requests anymore: |
633 |
|
|
|
634 |
|
|
BDB::poll_wait, BDB::poll_cb |
635 |
|
|
while BDB::nreqs; |
636 |
|
|
|
637 |
|
|
BDB::nready |
638 |
|
|
Returns the number of requests currently in the ready state (not yet |
639 |
|
|
executed). |
640 |
|
|
|
641 |
|
|
BDB::npending |
642 |
|
|
Returns the number of requests currently in the pending state |
643 |
|
|
(executed, but not yet processed by poll_cb). |
644 |
|
|
|
645 |
root |
1.14 |
COMMON PITFALLS |
646 |
|
|
Unexpected Crashes |
647 |
|
|
Remember that, by default, BDB will execute requests in parallel, in |
648 |
|
|
somewhat random order. That means that it is easy to run a "db_get" |
649 |
|
|
request on thesa me database as a concurrent "db_close" request, leading |
650 |
|
|
to a crash, silent data corruption, eventually the next world war on |
651 |
|
|
terrorism. |
652 |
|
|
|
653 |
|
|
If you only ever use foreground requests (without a callback), this will |
654 |
|
|
not be an issue. |
655 |
|
|
|
656 |
|
|
Unexpected Freezes or Deadlocks |
657 |
|
|
Remember that, by default, BDB will execute requests in parallel, which |
658 |
|
|
easily leads to deadlocks (even concurrent put's on the same database |
659 |
|
|
can deadlock). |
660 |
|
|
|
661 |
|
|
You either need to run deadlock detection (and handle the resulting |
662 |
|
|
errors), or make sure only one process ever updates the database, ine |
663 |
|
|
one thread, e.g. by using only foreground requests (without a callback). |
664 |
|
|
|
665 |
|
|
FORK BEHAVIOUR |
666 |
root |
1.3 |
This module should do "the right thing" when the process using it forks: |
667 |
|
|
|
668 |
root |
1.4 |
Before the fork, BDB enters a quiescent state where no requests can be |
669 |
|
|
added in other threads and no results will be processed. After the fork |
670 |
|
|
the parent simply leaves the quiescent state and continues |
671 |
root |
1.3 |
request/result processing, while the child frees the request/result |
672 |
|
|
queue (so that the requests started before the fork will only be handled |
673 |
|
|
in the parent). Threads will be started on demand until the limit set in |
674 |
|
|
the parent process has been reached again. |
675 |
|
|
|
676 |
|
|
In short: the parent will, after a short pause, continue as if fork had |
677 |
root |
1.4 |
not been called, while the child will act as if BDB has not been used |
678 |
|
|
yet. |
679 |
root |
1.3 |
|
680 |
root |
1.5 |
Win32 note: there is no fork on win32, and perls emulation of it is too |
681 |
|
|
broken to be supported, so do not use BDB in a windows pseudo-fork, |
682 |
|
|
better yet, switch to a more capable platform. |
683 |
|
|
|
684 |
root |
1.14 |
MEMORY USAGE |
685 |
root |
1.3 |
Per-request usage: |
686 |
|
|
|
687 |
|
|
Each aio request uses - depending on your architecture - around 100-200 |
688 |
|
|
bytes of memory. In addition, stat requests need a stat buffer (possibly |
689 |
|
|
a few hundred bytes), readdir requires a result buffer and so on. Perl |
690 |
|
|
scalars and other data passed into aio requests will also be locked and |
691 |
|
|
will consume memory till the request has entered the done state. |
692 |
|
|
|
693 |
|
|
This is not awfully much, so queuing lots of requests is not usually a |
694 |
|
|
problem. |
695 |
|
|
|
696 |
|
|
Per-thread usage: |
697 |
|
|
|
698 |
|
|
In the execution phase, some aio requests require more memory for |
699 |
|
|
temporary buffers, and each thread requires a stack and other data |
700 |
|
|
structures (usually around 16k-128k, depending on the OS). |
701 |
|
|
|
702 |
root |
1.14 |
WIN32 FILENAMES/DATABASE NAME MESS |
703 |
|
|
Perl on Win32 supports only ASCII filenames (the reason is that it |
704 |
|
|
abuses an internal flag to store wether a filename is Unicode or ANSI, |
705 |
|
|
but that flag is used for somethign else in the perl core, so there is |
706 |
|
|
no way to detect wether a filename is ANSI or Unicode-encoded). The BDB |
707 |
|
|
module tries to work around this issue by assuming that the filename is |
708 |
|
|
an ANSI filename and BDB was built for unicode support. |
709 |
|
|
|
710 |
root |
1.3 |
KNOWN BUGS |
711 |
|
|
Known bugs will be fixed in the next release, except: |
712 |
|
|
|
713 |
|
|
If you use a transaction in any request, and the request returns |
714 |
|
|
with an operating system error or DB_LOCK_NOTGRANTED, the internal |
715 |
|
|
TXN_DEADLOCK flag will be set on the transaction. See C<db_txn_finish>, |
716 |
|
|
above. |
717 |
|
|
|
718 |
|
|
SEE ALSO |
719 |
root |
1.9 |
AnyEvent::BDB (event loop integration), Coro::BDB (more natural syntax), |
720 |
|
|
IO::AIO (nice to have). |
721 |
root |
1.3 |
|
722 |
|
|
AUTHOR |
723 |
|
|
Marc Lehmann <schmorp@schmorp.de> |
724 |
|
|
http://home.schmorp.de/ |
725 |
|
|
|