![](bg3.png)
be moved to another bucket. One record is stored in
one bucket.
In OOSDDS an object may be bigger than a size
of the datagram. Hence, an overflow of a bucket may
occur when n-th slice of the object is transmitted. It
complicates a control of the bucket and the split algo-
rithm. There are at least two feasible solutions of this
problem. These are as follows:
1. To allow for storing slices of an object in many
buckets. Object ID must be supplemented by slice
ID. A bucket should control a pair of slice ID’s
identifying the first and to the last slice of stored
objects. The objects might be placed at the top
and the bottom of the bucket. Client image and a
kernel must be modified: for every bucket maxi-
mal value of slice ID must be added to maximal
value of object ID. This solution can be applied
only when objects are stored in buckets in serial-
ized form.
2. To allow for storing all slices of an object only
in one bucket. Overloading of the bucket might
be checked after transmission of the first or of
the last slice of the object. However, when more
(than one) clients add objects concurrently and
the checking is done after transmission of the last
slice of the object then the bucket can be over-
loaded too much. This does not happen when
the checking is done after transmission of the first
slice of the object. If the bucket would be over-
loaded after addition of the whole object this is
postponed. The bucket splits and then the object
is added to the proper bucket.
OOSDDS should be transparent for users. It should
work properly no respect whether an object moves
from one server to another or not. Therefore, the
architecture for serialized objects is chosen in OOS-
DDS. For the other architecture a transparency is un-
feasible because the results might rely on a server. Se-
rialization can also be used to ensure persistence.
5 IMPLEMENTATION OF RP*
FOR JAVA OBJECTS
An implementation of OOSDDSRP architecture for
Java objects should allow for storing, updating, re-
trieving and deleting individual objects of a class de-
fined by a user, with such restrictions on classes which
might be easy accepted (i.e. classes must be serializ-
able).
Objects stored in OOSDDS are distributed among
many servers. Hence, they should have some ex-
tra features. This can be achieved in different ways.
These are as follows:
- modification of a source code of a class, what re-
quires an access to this source code,
- modification of Java Virtual Machine (JVM), but
not all licenses allow to do that, additionally per-
manent modification of JVM affects other appli-
cations,
- modification of compiled byte code to gain re-
quired features, what means that the source code
is not necessary and is left unchanged.
To store objects of some class in OOSDDS the class
must contain its own mandatory methods and at-
tributes. A solution based on inheritance can not
be applied here as Java class can only extend one
base class. A programmer could probably add these
method and attributes manually but it excludes trans-
parency. For these reasons the last from the above
options that is modification of a byte code is chosen.
The program called SDDSModifier modifies com-
piled class and adds all required features. Objects are
stored in serialized form. They are converted into ta-
bles of bytes, transmitted and then stored in the buck-
ets on servers. Because of its popularity and univer-
sality Java collection is chosen as a method of ac-
cessing objects. The collections, besides tables, are
probably the second primary method of arranging ob-
jects. All collections implement one of two inter-
faces: Collection which is basis for lists and sets, and
Map which is used to map keys to values. Interface
SDDSCollection, which extends Collection, and class
SDDSFile, which implements it are then developed.
Summarizing, the development of scalable, dis-
tributed store of Java objects consists of two steps.
First a programmer develops an application which
uses SDDSFile to store objects. The application may
use classes which are stored in OOSDDS and other
classes not related with OOSDDS. Next, the classes
are compiled using a standard Java compiler and then
modified by SDDSModifier. SDDSModifier does
what follows:
- add an implementation of required interface,
- add or modify an implementation of required
methods,
- add an implementation of required attributes,
- modify the way of accessing specific attributes
(access by references is replaced by invocation of
auto-generated static methods).
Finally, after starting servers the application may be
launched. Every server may work in textual or graph-
ical mode.
ICEIS 2008 - International Conference on Enterprise Information Systems
376