A Freeze map is a persistent, associative container in which the key and value types can be any primitive or user-defined Slice types. For each pair of key and value types, the developer uses a code-generation tool to produce a language-specific class that conforms to the standard conventions for maps in that language. For example, in C++, the generated class resembles a
std::map, and in Java it implements the
java.util.SortedMap interface. Most of the logic for storing and retrieving state to and from the database is implemented in a Freeze base class. The generated map classes derive from this base class, so they contain little code and therefore are efficient in terms of code size.
You can only store data types that are defined in Slice in a Freeze map. Types without a Slice definition (that is, arbitrary C++ or Java types) cannot be stored because a Freeze map reuses the Ice-generated marshaling code to create the persistent representation of the data in the database. This is especially important to remember when defining a Slice class whose instances will be stored in a Freeze map; only the "public" (Slice-defined) data members will be stored, not the private state members of any derived implementation class.
As illustrated in Figure 40.2, a Freeze map is associated with a single connection and a single database file. Connection and map objects are not thread-safe: if you want to use a connection or any of its associated maps from multiple threads, you must serialize access to them. If your application requires concurrent access to the same database file (persistent map), you must create several connections and associated maps.
You may optionally use transactions with Freeze maps. Freeze transactions provide the usual ACID (atomicity, concurrency, isolation, durability) properties. For example, a transaction allows you to group several database updates in one atomic unit: either all or none of the updates within the transaction occur.
You start a transaction by calling beginTransaction on the
Connection object. Once a connection has an associated transaction, all operations on the map objects associated with this connection use this transaction. Eventually, you end the transaction by calling
commit or
rollback:
commit saves all your updates while
rollback undoes them. The
currentTransaction operation returns the transaction associated with a connection, if any; otherwise, it returns nil.
module Freeze {
local interface Transaction {
void commit();
void rollback();
};
local interface Connection {
Transaction beginTransaction();
idempotent Transaction currentTransaction();
// ...
};
};
If you do not use transactions, every non-iterator update is enclosed in its own internal transaction, and every read-write iterator has an associated internal transaction that is committed when the iterator is closed.
ConnectionPtr connection = ...;
TransactionPtr tx;
try {
tx = connection‑>beginTransaction();
// DB updates that might throw here...
tx‑>commit();
// More code that might throw here...
} catch (...) {
try {
tx‑>rollback();
} catch (...) {
}
throw;
}
The outer try-catch blocks are necessary because, if the code encounters an exception, we must roll back any updates that were made. In turn, the attempt to roll back might throw itself, namely, if the code following the commit throws an exception (in which case the transaction cannot be rolled back because it is already committed).
Code such as this is difficult to maintain: for example, an early return statement can cause the transaction to be neither committed nor rolled back. The
TransactionHolder class ensures that such errors cannot happen:
namespace Freeze {
class TransactionHolder {
public:
TransactionHolder(const ConnectionPtr&);
~TransactionHolder();
void commit();
void rollback();
private:
// Copy and assignment are forbidden.
TransactionHolder(const TransactionHolder&);
TransactionHolder& operator=(const TransactionHolder&);
};
}
ConnectionPtr connection = ...;
TransactionPtr tx;
try {
tx = connection‑>beginTransaction();
// DB updates that might throw here...
tx‑>commit();
// More code that might throw here...
} catch (...) {
try {
tx‑>rollback();
} catch (...) {
}
throw;
}
The catch block is necessary because, if the code in the try block throws an exception, we must roll back any updates that were made. In turn, the attempt to roll back might throw itself, namely, if the code following the commit throws an exception (in which case the transaction cannot be rolled back because it is already committed).
Code such as this is difficult to maintain: for example, an early return statement can cause the transaction to be neither committed nor rolled back. The
TransactionHolder class ensures that such errors cannot happen:
namespace Freeze {
class TransactionHolder {
public:
TransactionHolder(const ConnectionPtr&);
~TransactionHolder();
void commit();
void rollback();
private:
// Copy and assignment are forbidden.
TransactionHolder(const TransactionHolder&);
TransactionHolder& operator=(const TransactionHolder&);
};
}
The constructor calls beginTransaction if the connection does not already have a transaction in progress, so instantiating the holder also starts a transaction. When the holder instance goes out of scope, its destructor calls
rollback on the transaction and suppresses any exceptions that the rollback attempt might throw. This ensures that the transaction is rolled back if it was not previously committed or rolled back and ensures that an early return or an exception cannot cause the transaction to remain open:
ConnectionPtr connection = ...;
{ // Open scope
TransactionHolder tx(connection); // Begins transaction
// DB updates that might throw here...
tx.commit();
// More code that might throw here...
} // Transaction rolled back here if not previously
// committed or rolled back.
If you instantiate a TransactionHolder when a transaction is already in progress, it does nothing: the constructor notices that it could not begin a new transaction and turns
commit,
rollback, and the destructor into no‑ops. For example, the nested
TransactionHolder instance in the following code is benign and does nothing:
ConnectionPtr connection = ...;
{ // Open scope
TransactionHolder tx(connection); // Begins transaction
// DB updates that might throw here...
{ // Open nested scope
TransactionHolder tx2(connection); // Does nothing
// DB updates that might throw here...
tx2.commit(); // Does nothing
// More code that might throw here...
} // Destructor of tx2 does nothing
tx.commit();
// More code that might throw here...
} // Transaction rolled back here if not previously
// committed or rolled back.
Connection connection = ...;
Transaction tx = null;
try {
tx = connection.beginTransaction();
// DB updates that might throw here...
tx.commit();
// More code that might throw here...
} catch (java.lang.RuntimeException ex) {
try {
tx.rollback();
} catch (DatabaseException e) {
}
throw ex;
}
The catch handler ensures that the transaction is rolled back before re-throwing the exception. Note that the nested try-catch blocks are necessary: if the transaction committed successfully, but the code following the commit throws an exception, the rollback attempt will fail, so we need to suppress the corresponding
DatabaseException that is raised in that case.
Connection connection = ...;
Transaction tx = null;
try {
tx = connection.beginTransaction();
// DB updates that might throw here...
if (error) {
// ...
return; // Oops, bad news!
}
// ...
tx.commit();
// More code that might throw here...
} catch (java.lang.RuntimeException ex) {
try {
tx.rollback();
} catch (DatabaseException e) {
}
throw ex;
}
The early return statement in the preceding code causes the transaction to be neither committed or rolled back. To deal with this situation, avoid early return statements or ensure that you either commit or roll back the transaction before returning. Alternatively, you can use a
finally block to ensure that the transaction is rolled back:
Connection connection = ...;
try {
Transaction tx = connection.beginTransaction();
// DB updates that might throw here...
if (error) {
// ...
return; // No problem, see finally block.
}
// ...
tx.commit();
// More code that might throw here...
} finally {
if (connection.currentTransaction() != null)
connection.currentTransaction().rollback();
}
Iterators allow you to traverse the contents of a Freeze map. Iterators are implemented using Berkeley DB cursors and acquire locks on the underlying database page files. In C++, both read-only (
const_iterator) and read-write iterators (
iterator) are available; in Java, only read-write iterators are supported.
Locks held by an iterator are released when the iterator is closed (if you do not use transactions) or when the enclosing transaction ends. Releasing locks held by iterators is very important to let other threads access the database file through other connection and map objects. Occasionally, it is even necessary to release locks to avoid self-deadlock (waiting forever for a lock held by an iterator created by the same thread).
To improve ease of use and make self-deadlocks less likely, Freeze often closes iterators automatically. If you close a map or connection, associated iterators are closed. Similarly, when you start or end a transaction, Freeze closes all the iterators associated with the corresponding maps. If you do not use transactions, any write operation on a map (such as inserting a new element) automatically closes all iterators opened on the same map object, except for the current iterator when the write operation is performed through that iterator.
Read operations never close iterators automatically. In that situation, you need to either use transactions or explicitly close the iterator that holds the write lock.
If you use multiple threads to access a database file, Berkeley DB may acquire locks in conflicting orders (on behalf of different transactions or iterators). For example, an iterator could have a read-lock on page P1 and attempt to acquire a write-lock on page P2, while another iterator (on a different map object associated with the same database file) could have a read-lock on P2 and attempt to acquire a write-lock on P1.
When this occurs, Berkeley DB detects a deadlock and resolves it by returning a "deadlock" error to one or more threads. For all non-iterator operations performed outside any transaction, such as an insertion into a map, Freeze catches such errors and automatically retries the operation until it succeeds. (In that case, the most-recently acquired lock is released before retrying.) For other operations, Freeze reports this deadlock by raising
Freeze::DeadlockException. In that case, the associated transaction or iterator is also automatically rolled back or closed. A properly written application is expected to catch deadlock exceptions and retry the transaction or iteration.
Keys in Freeze maps and indexes are always sorted. By default, Freeze sorts keys according to their Ice-encoded binary representation; this is very efficient but the resulting order is rarely meaningful for the application.
Starting with Ice 3.0, Freeze offers the ability to specify your own comparator objects. In C++, you specify these comparators as options to the
slice2freeze utility (see below). In Java, the generated Java map class provides a number of constructors to accept these comparator objects.
The generated map provides the standard features of std::map (in C++) and
java.util.SortedMap (in Java). Iterators return entries according to the order you have defined for the main key with your comparator object. In C++,
lower_bound,
upper_bound, and
equal_range provide range-searches (see the definition of these functions on
std::map). In Java, use
headMap,
tailMap, and
subMap for range-searches; these methods come from the
java.util.SortedMap interface.
Apart from these standard features, the generated map provides additional functions and methods to perform range searches using secondary keys. In C++, the additional functions are
lowerBoundForMember,
upperBoundForMember, and
equalRangeForMember, where
Member is the name of the secondary-key member. These functions return regular iterators on the Freeze map.
public java.util.SortedMap
headMapForIndex(String indexName, Object toKey)
public java.util.SortedMap
tailMapForIndex(String indexName, Object fromKey)
public java.util.SortedMap
subMapForIndex(String indexName,
Object fromKey,
Object toKey)
The key of the returned submap is the secondary key (the index), and its value is a java.util.Set of
Map.Entry objects from the main Freeze map. This set provides all the entries in the main Freeze map with the given secondary key. When iterating over this submap, you may need to close iterators explicitly, such as iterators obtained for the main Freeze map. (See
Section 40.3.3 for more information.)
Please note that the key comparator of a Freeze map should remain the same throughout the life of this map. Berkeley DB stores records according to the key order provided by this comparator; switching to another comparator will cause undefined behavior.
Freeze maps support efficient reverse lookups: if you define an index when you generate your map (with
slice2freeze or
slice2freezej), the generated code provides additional methods for performing reverse lookups. If your value type is a structure or a class, you can also index on a member of the value, and several such indexes can be associated with the same Freeze map.
Indexed searches are easy to use and very efficient. However, be aware that an index adds significant write overhead: with Berkeley DB, every update triggers a read from the database to get the old index entry and, if necessary, replace it.
If you later add an index to an existing map, Freeze automatically populates the index the next time you open the map. Freeze populates the index by instantiating each map entry, so it is important that you register the object factories for any class types in your map before you open the map.
Please note that the index key comparator of a Freeze map index should remain the same throughout the life of the index. Berkeley DB stores records according to the key order provided by this comparator; switching to another comparator will cause undefined behavior.
The Slice-to-Freeze compiler, slice2freeze, creates C++ classes for Freeze maps. The compiler offers the following command-line options in addition to the standard options described in
Section 4.20:
•
‑‑add‑header HDR[,GUARD]#ifndef __PRECOMPILED_H__
#define __PRECOMPILED_H__
#include <precompiled.h>
#endif
Modifies #include directives in source files to prepend the path name of each header file with the directory
DIR. See
Section 6.15.1 for more information.
Use SYMBOL to control DLL exports or imports. See the
slice2cpp description for details.
•
‑‑dict NAME,
KEY,
VALUE[,sort[,COMPARE]]Generate a Freeze map class named NAME using
KEY as key and
VALUE as value. This option may be specified multiple times to generate several Freeze maps.
NAME may be a scoped C++ name, such as
Demo::Struct1ObjectMap. By default, keys are sorted using their binary Ice-encoded representation. Include
sort to sort with the
COMPARE functor class. If
COMPARE is not specified, the default value is
std::less<KEY>.
•
‑‑dict‑index MAP[,MEMBER]
[,case‑sensitive|case‑insensitive][,sort[,COMPARE]]Add an index to the Freeze map named MAP. If
MEMBER is specified, the map value type must be a structure or a class, and
MEMBER must be a member of this structure or class. Otherwise, the entire value is indexed. When the indexed member (or entire value) is a string, the index can be case-sensitive (default) or case-insensitive. An index adds additional member functions to the generated C++ map:
• int MEMBERCount(MEMBER_TYPE) const;
When MEMBER is not specified, these functions are
findByValue (const and non-const),
lowerBoundForValue (const and non-const),
valueCount, and so on. When
MEMBER is specified, its first letter is capitalized in the
findBy function name.
MEMBER_TYPE corresponds to an in-parameter of the type of
MEMBER (or the type of the value when
MEMBER is not specified). For example, if
MEMBER is a string,
MEMBER_TYPE is a
const std::string&.
findByMEMBER returns an iterator to the first element in the Freeze map that matches the given index value. It returns
end() if there is no match. When the second parameter is true (the default), the returned iterator provides only the elements with an exact match (and then skips to
end()). Otherwise, the returned iterator sets a starting position and then provides all elements until the end of the map, sorted according to the index comparator.
lowerBoundForMEMBER returns an iterator to the first element in the Freeze map whose index value is not less than the given index value. It returns
end() if there is no such element. The returned iterator provides all elements until the end of the map, sorted according to the index comparator.
upperBoundForMEMBER returns an iterator to the first element in the Freeze map whose index value is greater than the given index value. It returns
end() if there is no such element. The returned iterator provides all elements until the end of the map, sorted according to the index comparator.
beginForMEMBER returns an iterator to the first element in the map.
endForMEMBER returns an iterator to the last element in the map.
equalRangeForMEMBER returns a range (pair of iterators) of all the elements whose index value matches the given index value. This function is similar to
findByMEMBER (see above).
MEMBERCount returns the number of elements in the Freeze map whose index value matches the given index value.
•
‑‑index CLASS,TYPE,MEMBER
[,case‑sensitive|case‑insensitive]Generate an index class for a Freeze evictor (see Section 40.5.7).
CLASS is the name of the class to be generated.
TYPE denotes the type of class to be indexed (objects of different classes are not included in this index).
MEMBER is the name of the data member in
TYPE to index. When
MEMBER has type
string, it is possible to specify whether the index is case-sensitive or not. The default is case-sensitive.
Section 6.15.1 provides a discussion of the semantics of
#include directives that is also relevant for users of
slice2freeze.
$ slice2freeze ‑‑dict StringIntMap,string,int StringIntMap
This command directs the compiler to create a map named StringIntMap, with the Slice key type
string and the Slice value type
int. The final argument is the base name for the output files, to which the compiler appends the
.h and
.cpp suffixes. As a result, this command produces two C++ source files,
StringIntMap.h and
StringIntMap.cpp.
If you examine the contents of the header file created by the example in the previous section, you will discover that a Freeze map is an instance of the template class
Freeze::Map:
The Freeze::Map template class closely resembles the STL container class
std::map, as shown in the following class definition:
namespace Freeze {
template<...> class Map {
public:
typedef ... value_type;
typedef ... iterator;
typedef ... const_iterator;
typedef size_t size_type;
typedef ptrdiff_t difference_type;
Map(const Freeze::ConnectionPtr& connection,
const std::string& dbName,
bool createDb = true,
const Compare& compare = Compare());
template<class _InputIterator>
Map(const Freeze::ConnectionPtr& connection,
const std::string& dbName,
bool createDb,
_InputIterator first, _InputIterator last,
const Compare& compare = Compare());
static void recreate(const Freeze::ConnectionPtr& connection,
const std::string& dbName,
const Compare& compare = Compare());
bool operator==(const Map& rhs) const;
bool operator!=(const Map& rhs) const;
void swap(Map& rhs);
iterator begin();
const_iterator begin() const;
iterator end();
const_iterator end() const;
bool empty() const;
size_type size() const;
size_type max_size() const;
iterator insert(iterator /*position*/,
const value_type& elem);
std::pair<iterator, bool> insert(const value_type& elem);
template <typename InputIterator>
void insert(InputIterator first, InputIterator last);
void put(const value_type& elem);
template <typename InputIterator>
void put(InputIterator first, InputIterator last);
void erase(iterator position);
size_type erase(const key_type& key);
void erase(iterator first, iterator last);
void clear();
void destroy(); // Non‑standard.
iterator find(const key_type& key);
const_iterator find(const key_type& key) const;
size_type count(const key_type& key) const;
iterator lower_bound(const key_type& key);
const_iterator lower_bound(const key_type& key) const;
iterator upper_bound(const key_type& key);
const_iterator upper_bound(const key_type& key) const;
std::pair<iterator, iterator>
equal_range(const key_type& key);
std::pair<const_iterator, const_iterator>
equal_range(const key_type& key) const;
const Ice::CommunicatorPtr&
communicator() const;
...
};
}
The semantics of the Freeze::Map methods are identical to those of
std::map unless otherwise noted. In particular, the overloaded
insert method shown below ignores the
position argument:
iterator insert(iterator /*position*/,
const value_type& elem);
A Freeze map class supports only those methods shown above; other features of std::map, such as allocators and overloaded array operators, are not available.
Map(const Freeze::ConnectionPtr& connection,
const std::string& dbName,
bool createDb = true,
const Compare& compare = Compare());
template<class _InputIterator>
Map(const Freeze::ConnectionPtr& connection,
const std::string& dbName,
bool createDb,
_InputIterator first, _InputIterator last,
const Compare& compare = Compare());
The recreate function copies an existing database:
static void recreate(const Freeze::ConnectionPtr& connection,
const std::string& dbName,
const Compare& compare = Compare())
The dbName parameter specifies an existing database name. The copy has the name
<dbName>.old-<uuid>. For example, if the database name is
MyDB, the copy might be named
MyDB.old-edefd55a-e66a-478d-a77b-f6d53292b873. (Obviously, a different UUID is used each time you recreate a database).
A Freeze map’s iterator works like its counterpart in std::map. The iterator class supports one convenient (but nonstandard) method:
The program below demonstrates how to use a StringIntMap to store <
string,
int> pairs in a database. You will notice that there are no explicit
read or
write operations called by the program; instead, simply using the map has the side effect of accessing the database.
#include <Freeze/Freeze.h>
#include <StringIntMap.h>
int
main(int argc, char* argv[])
{
// Initialize the Communicator.
//
Ice::CommunicatorPtr communicator =
Ice::initialize(argc, argv);
// Create a Freeze database connection.
//
Freeze::ConnectionPtr connection =
Freeze::createConnection(communicator, "db");
// Instantiate the map.
//
StringIntMap map(connection, "simple");
// Clear the map.
//
map.clear();
Ice::Int i;
StringIntMap::iterator p;
// Populate the map.
//
for (i = 0; i < 26; i++) {
std::string key(1, 'a' + i);
map.insert(make_pair(key, i));
}
// Iterate over the map and change the values.
//
for (p = map.begin(); p != map.end(); ++p)
p.set(p‑>second + 1);
// Find and erase the last element.
//
p = map.find("z");
assert(p != map.end());
map.erase(p);
// Clean up.
//
connection‑>close();
communicator‑>destroy();
return 0;
}
The second argument is the name of a Berkeley DB database environment; by default, this is also the file system directory in which Berkeley DB creates all database and administrative files. Note that properties with the prefix
Freeze.DbEnv can modify a number of environment settings (see
page 1855), including the file system directory. For the preceding example, you could change the directory to
FreezeDir by setting the property
Freeze.DbEnv.db.DbHome to
FreezeDir.
Next, the code instantiates the StringIntMap on the connection. The constructor’s second argument supplies the name of the database file, which by default is created if it does not exist:
Iterating over the map will look familiar to std::map users. However, to modify a value at the iterator’s current position, we use the nonstandard
set method:
The Slice-to-Freeze compiler, slice2freezej, creates Java classes for Freeze maps. The compiler offers the following command-line options in addition to the standard options described in
Section 4.20:
Generate a Freeze map class named NAME using
KEY as key and
VALUE as value. This option may be specified multiple times to generate several Freeze maps.
NAME may be a scoped Java name, such as
Demo.Struct1ObjectMap.
•
‑‑dict‑index MAP[,MEMBER]
[,case‑sensitive|case‑insensitive]Add an index to the Freeze map named MAP. If
MEMBER is specified, the map value type must be a structure or a class, and
MEMBER must be a member of that type. If
MEMBER is not specified, the entire value is indexed. When the indexed member (or entire value) is a string, the index can be case-sensitive (default) or case-insensitive.
When MEMBER is not specified, these functions are
findbyValue and
valueCount. When
MEMBER is specified, its first letter is capitalized in the
findBy function name.
MEMBER_TYPE corresponds to an in-parameter of the type of
MEMBER (or the type of the value when
MEMBER is not specified). For example, if
MEMBER is a string,
MEMBER_TYPE is a
java.lang.String.
When MEMBER is not specified, these functions are
findbyValue and
valueCount.
java.util.Comparator myIndexKeyComparator = ...;
String myIndexName = ...;
java.util.Map indexComparators = new java.util.HashMap();
indexComparators.put(myIndexName, myIndexKeyComparator);
MyIndexedFreezeMap map =
new MyIndexedFreezeMap(connection, dbName, true,
myMainKeyComparator,
indexComparators);
findByMEMBER returns an iterator over elements of the Freeze map starting with an element with whose index value matches the given index value. If there is no such element, the returned iterator is empty (
hasNext always returns false). When the second parameter is true (or is not provided), the returned iterator provides only "duplicate" elements, that is, elements with the very same index value. Otherwise, the iterator sets a starting position in the map, and then provides elements until the end of the map, sorted according to the index comparator.
MEMBERCount returns the number of elements in the Freeze map whose index-value matches the given index value.
•
‑‑index CLASS,
TYPE,
MEMBER
[,case‑sensitive|case‑insensitive]Generate an index class for a Freeze evictor (see Section 40.5.7).
CLASS is the name of the index class to be generated.
TYPE denotes the type of class to be indexed (objects of different classes are not included in this index).
MEMBER is the name of the data member in
TYPE to index. When
MEMBER has type
string, it is possible to specify whether the index is case-sensitive or not. The default is case-sensitive.
$ slice2freezej ‑‑dict StringIntMap,string,int
This command directs the compiler to create a map named StringIntMap, with the Slice key type
string and the Slice value type
int. The compiler produces one Java source file:
StringIntMap.java.
If you examine the contents of the source file created by the example in the previous section, you will discover that a Freeze map is a subclass of
Freeze.Map:
public class StringIntMap extends Freeze.Map {
public StringIntMap(Freeze.Connection connection,
String dbName,
boolean createDb,
java.util.Comparator comparator);
public StringIntMap(Freeze.Connection connection,
String dbName,
boolean createDb);
public StringIntMap(Freeze.Connection connection,
String dbName);
}
The map’s base class, Freeze.Map, implements standard Java interfaces and provides nonstandard methods that improve efficiency and support database-oriented features such as indexes:
package Freeze;
public abstract class Map extends java.util.AbstractMap
implements java.util.SortedMap ... {
//
// Methods from java.util.AbstractMap and java.util.SortedMap.
...
//
// Nonstandard methods.
public java.util.SortedMap headMapForIndex(String indexName,
Object toKey);
public java.util.SortedMap tailMapForIndex(String indexName,
Object fromKey);
public java.util.SortedMap subMapForIndex(String indexName,
Object fromKey,
Object toKey);
public java.util.SortedMap mapForIndex(String indexName);
public void fastPut(Object key, Object value);
public boolean fastRemove(Object key);
public void closeAllIterators();
public void close();
}
For the sake of brevity, we have omitted the methods inherited from java.util.AbstractMap and
java.util.SortedMap; refer to the JDK documentation for more details.
Several methods are provided that support Freeze indexes. These methods mirror the semantics of the methods from
java.util.SortedMap, except that a particular index is selected for ordering purposes. (
mapForIndex returns a map for then entire index).
The fastPut and
fastRemove methods are more efficient versions of the standard
put and
remove, respectively. In contrast to the standard methods,
fastPut and
fastRemove do not return the prior value associated with the key, thereby eliminating the overhead of reading and decoding it. The boolean value returned by
fastRemove indicates whether an element was found with the given key.
As its name implies, the closeAllIterators method ensures that all outstanding iterators are closed. We discuss iterators in more depth in the next section.
Finally, the close method closes all outstanding iterators and then closes the database. A Freeze map is also closed implicitly when the object is finalized, but given the uncertain nature of Java’s garbage collection facility, we recommend explicitly closing a map when it is no longer needed.
You can iterate over a Freeze map just as you can with any container that implements the
java.util.Map interface. For example, the code below displays the key and value of each element:
StringIntMap m = ...;
java.util.Iterator i = m.entrySet().iterator();
while (i.hasNext()) {
java.util.Map.Entry e = (java.util.Map.Entry)i.next();
System.out.println("Key: " + e.getKey());
System.out.println("Value: " + e.getValue());
}
When an iterator is no longer necessary, a program should explicitly close it. (An iterator that is garbage collected without being closed emits a warning message.) To close an iterator, you must cast it to a Freeze-specific type, as shown below:
The program below demonstrates how to use a StringIntMap to store <
string,
int> pairs in a database. You will notice that there are no explicit
read or
write operations called by the program; instead, simply using the map has the side effect of accessing the database.
public class Client
{
public static void
main(String[] args)
{
// Initialize the Communicator.
//
Ice.Communicator communicator = Ice.Util.initialize(args);
// Create a Freeze database connection.
//
Freeze.Connection connection =
Freeze.Util.createConnection(communicator, "db");
// Instantiate the map.
//
StringIntMap map =
new StringIntMap(connection, "simple", true);
// Clear the map.
//
map.clear();
int i;
java.util.Iterator p;
// Populate the map.
//
for (i = 0; i < 26; i++) {
final char[] ch = { (char)('a' + i) };
map.put(new String(ch), new Integer(i));
}
// Iterate over the map and change the values.
//
p = map.entrySet().iterator();
while (p.hasNext()) {
java.util.Map.Entry e = (java.util.Map.Entry)p.next();
Integer in = (Integer)e.getValue();
e.setValue(new Integer(in.intValue() + 1));
}
// Find and erase the last element.
//
boolean b;
b = map.containsKey("z");
assert(b);
b = map.fastRemove("z");
assert(b);
// Clean up.
//
map.close();
connection.close();
communicator.destroy();
System.exit(0);
}
}
The second argument is the name of a Berkeley DB database environment; by default, this is also the file system directory in which Berkeley DB creates all database and administrative files.
Next, the code instantiates the StringIntMap on the connection. The constructor’s second argument supplies the name of the database file, and the third argument indicates that the database should be created if it does not exist:
p = map.entrySet().iterator();while (p.hasNext()) {
java.util.Map.Entry e =
(java.util.Map.Entry)p.next();
Integer in = (Integer)e.getValue();
e.setValue(new Integer(in.intValue() + 1));
}
