Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[smila-dev] RE: BinaryStorage JPA Implementation

hi daniel,

good thing todo.

in regard to the config i completely agree.

as a next step I was wondering if it makes sense to actually merge record and binary storage into the same DB as both are now JPA implementations.

I see this initially as an option but I think that it makes more sense to store all in the same storage, looking from the transactional side of things. 
however, I would not want this to be mandatory right now due to use cases where the storage needs of binaries and records could get so high that not one single instance can hold it.

I also think that we need to spec and discuss this more in detail 
- the changes that this will trigger elsewhere.
- in the context of clustering
- etc.

Kind regards
Thomas Menzel @ brox IT-Solutions GmbH

-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel.Stucky@xxxxxxxxxxx
Sent: Donnerstag, 2. Juli 2009 11:31
To: smila-dev@xxxxxxxxxxx
Subject: [smila-dev] BinaryStorage JPA Implementation 

Hi all,

I have added a BinaryStorage persistence implementation based on
EclipseLink with JPA and updated
http://wiki.eclipse.org/SMILA/Documentation/Binary_Storage. There are 2
new bundles you have to check out:
- eclipse.smila.binarystorage.persistence.jpa
- eclipse.smila.binarystorage.persistence.jpa.test

To use the JPA implementation just set
implementationClass="org.eclipse.smila.binarystorage.persistence.jpa.JPA
BinaryPersistence" in file
org.eclipse.smila.binarystorage.impl/BinaryStorageConfiguration.xml. 

The JPA implementation comes with its own configuration file
org.eclipse.smila.binarystorage.persistence.jpa/persistence.properties.
All configuration options (except implementationClass) of
BinaryStorageConfiguration.xml are not used !

I propose to change this configuration, as configuration of different
implementations may vary highly (we can see this now as the JPA
configuration has nothing in common with io or EFS). Each persistence
bundle should have its own configuration file (as we did it with other
bundles, too) and the BinaryStorage service should not need to pass it's
configuration file to the persistence layer, as it only needs to know
what persistence implementation to use.


I compared the JPA implementation to our default configuration
(IOHierarchicalManager with a pathDepth of 2). 
The JPA implementation was a little faster (no real magnitude) but it
consumed about 60% more memory (in this case about 100 MB more). The
disk space used was almost identical, but cleaning up the JPA
implementation is way faster (no file hierarchy to delete).


Feedback is most welcome.

Bye,
Daniel
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev


Back to the top