db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luigi Lauro (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2469) Java Web Start JNLP PersistenceService API storage support
Date Tue, 12 Jun 2007 08:35:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503777

Luigi Lauro commented on DERBY-2469:

Ok, I answer to you all on the several issues, in several upcoming comments :)

Summary of the patch (@Dan): currently derby supports only several storage system for the
database file persistence. The aim of this patch is to add a new Storage system for derby,
built upon the JNLP PersistenceService API, which is a sun provided persistence service meant
to be used in java web start environments (web apps or web-deployed desktop apps, as the one
I'm developing), and is meant to be sandbox friendly (no 'give me full access to your HD'
popups as per using the standard file factory).

To get in depth, my implementation is currently made up of two implementation classes and
an abstract class.

AbstractStorageFactory: abstract base class implementing StorageFactory interface. This is
meant to be a base class for StorageFactory implementation classes, and it's a sort of 'cleaned
up' and rewritten from scratch version of derby BaseStorageFactory class. It provides basic
initialization logic for needed database/temp directories, and it also gives a standard temporary
files implementation, using standard files.

JNLPStorageFactory: Java Web Start based StorageFactory implementation using JNLPStorageFile
classes for file entities. All the persistence operations are delegated to JNLPStorageFile
instances, which make use of the JNLP PersistenceService API provided by the Java Web Start
framework, which is a sandbox friendly persistent storage available to JWS-enabled applications.

Persistence is based on a cookie-like mechanism which stores persistent entities associated
with URLs. We build hierarchy upon this flat structure by using a implicit naming hierarchy.

Mapping is currently 1-1 (PersistenceEntity <---> Derby StorageFile) because I wanted
to keep the implementation simple and straightforward, and this limits current applications
of this factory till the sun PersistenceService implementation bug of maximum 255 persistence
entries have been fixed (probably in next update, from the informations I have from Sun).
This means the whole factory will fail horribly as soon as Derby asks for more than 255 storage

The current implementation use JNLP Storage entities even for temporary files (to avoid using
standard files, which will defy the whole purpose of this factory - making a sandbox friendly
JWS enabled factory), but I plan to plug in a in-memory implementation for the temp files,
in order to avoid spamming the persistence storage with temporary files (especially since
the 255 max entities bug, presently).

JNLP Storage Entities have no hierarchy, so I had to code an implicit one into the name, using
a special char (comma "," presently, as I thought it was the one  least probable to be seen
in URLs, but still valid).

A JNLP Storage entity therefore is associate with a given URL, which is usually something
like "http://APP_CODEBASE/DIR1,DIR2,DIR3,FILE" (ex: "http://www.derby.com/jnlp/directory,subdirectory,file")

Currently, the implementation scan the whole persistent entities list to find the 'files'
contained in a given directory, and parses all paths to find the entities that matches the
needed path. This could be optimized by using data structures for indexing the entities, in
order to avoid a full scan each time, but performance wise this should not be too much of
a problem given the max 255 entities limit and the fact the PersistenceService is pretty efficient
in retrieving the entities names. First make it work, then make it fast ;-)

> Java Web Start JNLP PersistenceService API storage support
> ----------------------------------------------------------
>                 Key: DERBY-2469
>                 URL: https://issues.apache.org/jira/browse/DERBY-2469
>             Project: Derby
>          Issue Type: New Feature
>          Components: Store
>    Affects Versions:
>         Environment: Java Web Start
>            Reporter: Luigi Lauro
>            Assignee: David Van Couvering
>            Priority: Minor
>             Fix For:
>         Attachments: svn-diff-20070329, svn-diff-20070606
> I would love to have Derby write/read to the storage area provided by the JNLP PersistenceService
> Since Derby is now bundled with the Java6 JDK as JavaDB, I think this  integration would
go a long way towards making derby more developer- friendly in Java Web Start environments,
where using the sandbox tools Sun provides us it the right way to go, instead of working 
around it and force the user to give the app the authorization to write on the hard drive
> I'm investigating the effort needed to provide an implementation of the WritableStorageFactory
interface around the PersistenceService API, and if that's doable in a few days work, I will
start working on it and submit a patch for testing/approval ASAP.
> Feel free to volounteer and provide pointers/hints/whatever, it's really appreciate,
especially since I currently know nothing of derby internals.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message