AW: [smila-dev] RE: BinaryStorage JPA Implementation

[<Daniel.Stucky@xxxxxxxxxxx>]

Hi Tom,

merging the tables of Record- and BinaryStorage into the same database is pretty easy with EclipseLink. It's just a matter of configuration by specifying the same database in the persistence.properties files of both bundles.

E.g. instead of using 
eclipselink.jdbc.url=
jdbc:derby:workspace/.metadata/.plugins/org.eclipse.smila.binarystorage.persistence.jpa/binarystorage;create=true
and 
eclipselink.jdbc.url=
jdbc:derby:workspace/.metadata/.plugins/org.eclipse.smila.recordstorage.impl/recordstorage;create=true

Just use
eclipselink.jdbc.url=
jdbc:derby:workspace/.metadata/.plugins/org.eclipse.smila.globalstorage.impl/globalstorage;create=true
in both files.


Bye,
Daniel

> -----Ursprüngliche Nachricht-----
> Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> bounces@xxxxxxxxxxx] Im Auftrag von Thomas Menzel
> Gesendet: Donnerstag, 2. Juli 2009 11:42
> An: Smila project developer mailing list
> Betreff: [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.JP
> A
> 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
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev