Skip to main content

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

+1 for changing the configuration so that each persistence bundle has its own configuration file.

Cheers
Igor



> -----Ursprüngliche Nachricht-----
> Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Daniel.Stucky@xxxxxxxxxxx
> Gesendet: Donnerstag, 2. Juli 2009 11:31
> An: smila-dev@xxxxxxxxxxx
> Betreff: [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