Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Difference between revisions of "SMILA/Documentation/Binary Storage"

m (Overview: added category)
Line 1: Line 1:
== Overview ==
== Overview ==

Revision as of 01:56, 17 October 2009


Binary Storage Service provides an easy way to store / access binary data documents.

Client components access the Binary Storage Service for persisting binary data (attachments) into the binary storage. The binary data are identified by a unique key / identifier as a String data type.


Currently, Binary Storage is able to run and store data into a hierarchical structure (uses deterministically calculation based on the hash id passed by the client component, like the ID passed from the Blackboard Service) and flat structure.

To configure the needed persistence storage structure, simply edit the /configuration/org.eclipse.smila.binarystorage/BinaryStorageConfiguration.xml file and change the value of implementationClass attribute to the one of the following available possibilities:

  • org.eclipse.smila.binarystorage.internal.impl.persistence.filesystem.IOHierarchicalManager
  • org.eclipse.smila.binarystorage.internal.impl.persistence.filesystem.IOFlatManager

In the next future there will be other available managers that provides the appropriate implementation for Binary Storage persistence structure.

The Binary Storage Configuration will be changed soon.

Configuration example

<BinaryStorageConfiguration xmlns="" 

Attributes explained:

  • name - configuration alias
  • implementationClass - binary storage implementation manager class
  • tempFileName - binary storage temporary file name
  • pathDepth - the depth of the folder structure (Note: If not set the default value is 2.)


void store(String id, InputStream stream);
void store(String id, byte[] blob)
byte[] fetchAsByte(String id)
InputStream fetchAsStream(String id)
void remove(String id)
int fetchSize(String id)

API Usage

BinaryStorageService binaryStorageService = ...; // Obtain the binary storage service
String attacmentIdKey = ...; // Unique ID
byte[] dataRecord = ... // Build record
// Store the binary record as byte array, dataRecord);
// Fetch record as stream
final InputStream stream = binaryStorageService.fetchAsStream(attacmentIdKey);
// Define new ID and store new data from the first record's input stream
final String newAttacmentIdKey = attacmentIdKey + "0000";, stream);
// Fetch the newest record as array of byte 
final byte[] recordByte = binaryStorageService.fetchAsByte(newAttacmentIdKey);
// The two records must have the same size
final int sizeInitial = _binaryStorageService.fetchSize(attacmentIdKey);
final int sizeFinal = binaryStorageService.fetchSize(newAttacmentIdKey);
// Remove the two records


Both I/O implementations use the id in the path name of the persisted file. As a consequence

  • the characters [;/\:] are not allowed in the id
  • too long ids will exceed the platform specific supported max. path length. this will result in a not so obvious error message, that saving failed.

ATM neither limitation this is a problem because the id is a hash made from letters and numbers.


The calculation of the path is simply to split the first part of the id into substrings of length 2 and make thees parent folders having the name of the id.

Care must be taken that the folder depth is not too high, because this results in a lot of folders quenching the performance of the file system.


If u only have a few files or ur underlying file system is very good inhandling lots of files per folder then go with this manager.


This implementation is based on EFS.


This implementation uses eclipseLink JPA to store binary objects in an apache derby database named BinaryStorage. The data is stored in table BINARY_OBJECTS:

Column Type Description
ID VARCHAR the Id of the binary object
BIN_OBJECT BLOB the binary object


In order to use this implementation you have to start bundle eclipse.smila.binarystorage.persistence.jpa in your launch configuration. Then set parameter implementationClass in file org.eclipse.smila.binarystorage.impl/BinaryStorageConfiguration.xml to org.eclipse.smila.binarystorage.persistence.jpa.JPABinaryPersistence. All other configuration options of file org.eclipse.smila.binarystorage.impl/BinaryStorageConfiguration.xml are ignored !

The other configuration needed is a typicall eclipseLink configuration property file. Therin you can specify settings for logging, database connection settings. For more information please refer to the eclipseLink documentation [[1]]. The configuration is located at configuration/org.eclipse.smila.binarystorage.persistence.jpa/

# EclipseLink properties

After starting Smila for the first time, the DDL generation setting will print out some nasty warnings, complaining that it can't create some tables. These warnings are not critical. You can get rid of them by setting eclipselink.ddl-generation=none, but only after Smila was started at least once (and the tables were created).


At the moment it is necessary to import all packages containing JDBCDriver classes in org.eclipse.smila.connectivity.deltaindexing.jpa.impl. So for changing from derby to another database it is not sufficient to change the configuration in, you also have to add import package statementsv for the JDBC driver to use to your bundles manifest. This will hopefully be changed with the next release of eclipseLink.

Back to the top