BerkeleyDB
view release on metacpan or search on metacpan
BerkeleyDB.pod view on Meta::CPAN
processes doing locking on the database. Default 1000.
=item -MaxLocks
If present, this parameter is used to configure the maximum number of
locks on the database. Default 1000. This is often lower than required.
=item -MaxObjects
If present, this parameter is used to configure the maximum number of
locked objects. Default 1000. This is often lower than required.
=item -SharedMemKey
If present, this parameter sets the base segment ID for the shared memory
region used by Berkeley DB.
This option requires Berkeley DB 3.1 or better.
Use C<$env-E<gt>get_shm_key($id)> to find out the base segment ID used
once the environment is open.
BerkeleyDB.pod view on Meta::CPAN
It is a fatal error to attempt to create a cds_lock if the Berkeley DB
environment has not been opened in CDS mode.
=head2 $lock->cds_unlock();
Removes a CDS lock. The destruction of the CDS lock object automatically
calls this method.
Note that if multiple CDS lock objects are created, the underlying write
lock will not be released until all CDS lock objects are either explicitly
unlocked with this method, or the CDS lock objects have been destroyed.
=head2 $ref = $db->db_stat()
Returns a reference to an associative array containing information about
the database. The keys of the associative array correspond directly to the
names of the fields defined in the Berkeley DB documentation. For example,
in the DB documentation, the field B<bt_version> stores the version of the
Btree database. Assuming you called B<db_stat> on a Btree database the
equivalent field would be accessed as follows:
BerkeleyDB.pod view on Meta::CPAN
above. Firstly, the existing value for the key "Counter" is fetched from
the database using C<db_get>. A read lock will be used for this part of the
update. The value is then incremented, and the new value is written back
to the database using C<db_put>. This time a write lock will be used.
Here's the problem - there is nothing to stop two (or more) processes
executing the read part at the same time. Remember multiple processes can
hold a read lock on the database at the same time. So both will fetch the
same value, let's say 7, from the database. Both increment the value to 8
and attempt to write it to the database. Berkeley DB will ensure that only
one of the processes gets a write lock, while the other will be blocked. So
the process that happened to get the write lock will store the value 8 to
the database and release the write lock. Now the other process will be
unblocked, and it too will write the value 8 to the database. The result,
in this example, is we have missed a hit in the counter.
To deal with this kind of scenario, you need to make the update atomic. A
convenience method, called C<cds_lock>, is supplied with the BerkeleyDB
module for this purpose. Using C<cds_lock>, the counter update code can now
be rewritten thus:
my $lk = $dbh->cds_lock() ;
$hash{Counter} ++ ;
$lk->cds_unlock;
BerkeleyDB.pod view on Meta::CPAN
until the cursor is deleted. This is how you create a write-cursor
$cursor = $db->db_cursor(DB_WRITECURSOR);
If you have instantiated multiple C<cds_lock> objects for one database
within a single process, that process will hold a write-lock on the
database until I<ALL> C<cds_lock> objects have been destroyed.
As with all write-cursors, you should try to limit the scope of the
C<cds_lock> to as short a time as possible. Remember the complete database
will be locked to other process whilst the write lock is in place.
=head2 Cannot write with a read cursor while a write cursor is active
This issue is easier to demonstrate with an example, so consider the code
below. The intention of the code is to increment the values of all the
elements in a database by one.
# Assume $db is a database opened in a CDS environment.
# Create a write-lock
BerkeleyDB.pod view on Meta::CPAN
while (my ($k, $v) = each %hash)
{
# do something
}
To implement the "each" functionality, a read cursor will be created behind
the scenes to allow you to iterate through the tied hash, C<%hash>. While
that cursor is still active, a read lock will obviously be held against the
database. If your application has any other writing processes, these will
be blocked until the read cursor is closed. That won't happen until the
loop terminates.
To avoid blocking problems, only keep cursors open as long as they are
needed. The same is true when you use the C<cursor> method or the
C<cds_lock> method.
The locking behaviour of the C<values> or C<keys> functions, shown below,
is subtly different.
BerkeleyDB.pod.P view on Meta::CPAN
processes doing locking on the database. Default 1000.
=item -MaxLocks
If present, this parameter is used to configure the maximum number of
locks on the database. Default 1000. This is often lower than required.
=item -MaxObjects
If present, this parameter is used to configure the maximum number of
locked objects. Default 1000. This is often lower than required.
=item -SharedMemKey
If present, this parameter sets the base segment ID for the shared memory
region used by Berkeley DB.
This option requires Berkeley DB 3.1 or better.
Use C<$env-E<gt>get_shm_key($id)> to find out the base segment ID used
once the environment is open.
BerkeleyDB.pod.P view on Meta::CPAN
It is a fatal error to attempt to create a cds_lock if the Berkeley DB
environment has not been opened in CDS mode.
=head2 $lock->cds_unlock();
Removes a CDS lock. The destruction of the CDS lock object automatically
calls this method.
Note that if multiple CDS lock objects are created, the underlying write
lock will not be released until all CDS lock objects are either explicitly
unlocked with this method, or the CDS lock objects have been destroyed.
=head2 $ref = $db->db_stat()
Returns a reference to an associative array containing information about
the database. The keys of the associative array correspond directly to the
names of the fields defined in the Berkeley DB documentation. For example,
in the DB documentation, the field B<bt_version> stores the version of the
Btree database. Assuming you called B<db_stat> on a Btree database the
equivalent field would be accessed as follows:
BerkeleyDB.pod.P view on Meta::CPAN
above. Firstly, the existing value for the key "Counter" is fetched from
the database using C<db_get>. A read lock will be used for this part of the
update. The value is then incremented, and the new value is written back
to the database using C<db_put>. This time a write lock will be used.
Here's the problem - there is nothing to stop two (or more) processes
executing the read part at the same time. Remember multiple processes can
hold a read lock on the database at the same time. So both will fetch the
same value, let's say 7, from the database. Both increment the value to 8
and attempt to write it to the database. Berkeley DB will ensure that only
one of the processes gets a write lock, while the other will be blocked. So
the process that happened to get the write lock will store the value 8 to
the database and release the write lock. Now the other process will be
unblocked, and it too will write the value 8 to the database. The result,
in this example, is we have missed a hit in the counter.
To deal with this kind of scenario, you need to make the update atomic. A
convenience method, called C<cds_lock>, is supplied with the BerkeleyDB
module for this purpose. Using C<cds_lock>, the counter update code can now
be rewritten thus:
my $lk = $dbh->cds_lock() ;
$hash{Counter} ++ ;
$lk->cds_unlock;
BerkeleyDB.pod.P view on Meta::CPAN
until the cursor is deleted. This is how you create a write-cursor
$cursor = $db->db_cursor(DB_WRITECURSOR);
If you have instantiated multiple C<cds_lock> objects for one database
within a single process, that process will hold a write-lock on the
database until I<ALL> C<cds_lock> objects have been destroyed.
As with all write-cursors, you should try to limit the scope of the
C<cds_lock> to as short a time as possible. Remember the complete database
will be locked to other process whilst the write lock is in place.
=head2 Cannot write with a read cursor while a write cursor is active
This issue is easier to demonstrate with an example, so consider the code
below. The intention of the code is to increment the values of all the
elements in a database by one.
# Assume $db is a database opened in a CDS environment.
# Create a write-lock
BerkeleyDB.pod.P view on Meta::CPAN
while (my ($k, $v) = each %hash)
{
# do something
}
To implement the "each" functionality, a read cursor will be created behind
the scenes to allow you to iterate through the tied hash, C<%hash>. While
that cursor is still active, a read lock will obviously be held against the
database. If your application has any other writing processes, these will
be blocked until the read cursor is closed. That won't happen until the
loop terminates.
To avoid blocking problems, only keep cursors open as long as they are
needed. The same is true when you use the C<cursor> method or the
C<cds_lock> method.
The locking behaviour of the C<values> or C<keys> functions, shown below,
is subtly different.
get_and_check_backslash_N_name_wrapper|5.029009||Viu
get_ANYOF_cp_list_for_ssc|5.019005||Viu
get_ANYOFM_contents|5.027009||Viu
GETATARGET|5.003007||Viu
get_aux_mg|5.011000||Viu
get_av|5.006000|5.003007|p
getc|5.003007||Viu
get_c_backtrace|5.021001||Vi
get_c_backtrace_dump|5.021001||V
get_context|5.006000|5.006000|nu
getc_unlocked|5.003007||Viu
get_cv|5.006000|5.003007|p
get_cvn_flags|5.009005|5.003007|p
get_cvs|5.011000|5.003007|p
getcwd_sv|5.007002|5.007002|
get_db_sub|||iu
get_debug_opts|5.008001||Viu
get_deprecated_property_msg|5.031011||cVniu
getegid|5.005000||Viu
getenv|5.005000||Viu
getenv_len|5.006000||Viu
PERL_MAGIC_vec|5.007002|5.003007|p
PERL_MAGIC_vstring|5.008001|5.003007|p
PERL_MAGIC_VTABLE_MASK|5.015000||Viu
PERL_MALLOC_CTL_H|5.027001||Viu
Perl_malloc_good_size|5.010001||Viu
PERL_MALLOC_WRAP|5.009002|5.009002|Vn
PerlMem_calloc|5.006000||Viu
PerlMem_free|5.005000||Viu
PerlMem_free_lock|5.006000||Viu
PerlMem_get_lock|5.006000||Viu
PerlMem_is_locked|5.006000||Viu
PerlMem_malloc|5.005000||Viu
PERL_MEMORY_DEBUG_HEADER_SIZE|5.019009||Viu
PerlMemParse_calloc|5.006000||Viu
PerlMemParse_free|5.006000||Viu
PerlMemParse_free_lock|5.006000||Viu
PerlMemParse_get_lock|5.006000||Viu
PerlMemParse_is_locked|5.006000||Viu
PerlMemParse_malloc|5.006000||Viu
PerlMemParse_realloc|5.006000||Viu
PerlMem_realloc|5.005000||Viu
PerlMemShared_calloc|5.006000||Viu
PerlMemShared_free|5.006000||Viu
PerlMemShared_free_lock|5.006000||Viu
PerlMemShared_get_lock|5.006000||Viu
PerlMemShared_is_locked|5.006000||Viu
PerlMemShared_malloc|5.006000||Viu
PerlMemShared_realloc|5.006000||Viu
PERL_MG_UFUNC|5.007001||Viu
Perl_modf|5.006000|5.006000|n
PERL_MULTICONCAT_HEADER_SIZE|5.027006||Viu
PERL_MULTICONCAT_IX_LENGTHS|5.027006||Viu
PERL_MULTICONCAT_IX_NARGS|5.027006||Viu
PERL_MULTICONCAT_IX_PLAIN_LEN|5.027006||Viu
PERL_MULTICONCAT_IX_PLAIN_PV|5.027006||Viu
PERL_MULTICONCAT_IX_UTF8_LEN|5.027006||Viu
PUSHSTACKi|5.005000||Viu
PUSHSTACK_INIT_HWM|5.027002||Viu
PUSHTARG|5.003007||Viu
PUSHu|5.004000|5.003007|p
PUTBACK|5.003007|5.003007|
putc|5.003007||Viu
put_charclass_bitmap_innards|5.021004||Viu
put_charclass_bitmap_innards_common|5.023008||Viu
put_charclass_bitmap_innards_invlist|5.023008||Viu
put_code_point|5.021004||Viu
putc_unlocked|5.003007||Viu
putenv|5.005000||Viu
put_range|5.019009||Viu
putw|5.003007||Viu
pv_display|5.006000|5.003007|p
pv_escape|5.009004|5.003007|p
pv_pretty|5.009004|5.003007|p
pv_uni_display|5.007003|5.007003|
pWARN_ALL|5.006000||Viu
pWARN_NONE|5.006000||Viu
pWARN_STD|5.006000||Viu
( run in 0.779 second using v1.01-cache-2.11-cpan-49f99fa48dc )