I'm also working on a connector that stores the graph in a DB using
Hibernate. It's not complete, so I don't have any numbers yet. But
it's coming along nicely, and I did try to solve some of the problems
with how JR persistence works.
On Nov 19, 2008, at 11:50 PM, Michael Neale wrote:
that sounds ideal. I know myself and others are not entirely
comfortable with jackrabbit - particularly the way it stores thing in
RDBMS (although if we are using jboss cache and its persistence - I am
not sure if we will do much better then blob storage??).
On Thu, Nov 20, 2008 at 3:05 PM, Randall Hauch <rhauch(a)redhat.com>
wrote:
> Actually, I'm hoping that we can support binary property values
> (which is
> actually where JCR stores file content, but you know that :-) in
> memory
> mapped (direct) buffers. That way, they don't take up any memory.
> Plus, by
> using federation and a file system connector, we could store these
> large
> files on the file system and just handle the "references" as property
> values, opening a stream to the underlying only when required. Of
> course,
> you're app would have to pay the price for streaming gigabytes of
> information. :-)
>
> How does this sound?
>
> Best regards,
>
> Randall
>
> On Nov 19, 2008, at 9:09 PM, Michael Neale wrote:
>
>> For our SOA repository, and rules - its possible we are looking at
>> large single artifacts, as well as many small ones (which kind of
>> stretch most JCR implementations). One idea floated is to (possibly)
>> one day store entire machine images (OMG !!!) in the repository
>> (obviously in memory will not work in that case !). But its hard to
>> nail things down isn't it...
>>
>> On Thu, Nov 20, 2008 at 7:21 AM, Randall Hauch <rhauch(a)redhat.com>
>> wrote:
>>>
>>> Stefano, this sounds great! Personally, I really like to hear
>>> these
>>> kinds
>>> of use cases and scenarios. It's always important to know
>>> whether we're
>>> working on the "right" set of features. So keep these use cases
>>> coming!
>>>
>>> And, please feel free to suggest or discuss features that might be
>>> useful,
>>> too. For example, do you think JCR versioning will be an
>>> important part
>>> of
>>> your approach, or will you implement your own approach to managing
>>> history
>>> by designing the hierarchy to handle it? Also, do you have an
>>> idea about
>>> how much information the repository will store (perhaps broken
>>> down by %
>>> in
>>> uploaded files, and about how big those files will each be).
>>>
>>> Best regards,
>>>
>>> Randall
>>>
>>> On Nov 18, 2008, at 3:34 PM, Stefano Maestri wrote:
>>>
>>>> Hi all,
>>>> as said in a previous post I'm going to start a SOA/Enterprise
>>>> project
>>>> using DNA for an important part of the project.
>>>> I'm finishing the design of the whole application, but I can
>>>> describe
>>>> here the main idea and how DNA will be related.
>>>>
>>>> In a nutshell we are SOAfing a complex system of a customer
>>>> (J2EE+.NET+Oracle mainly, with external partner and provider
>>>> with SOAP
>>>> service and/or custom legacy services).
>>>> The system use a lot of data stored in various resources (mainly
>>>> relationl DB, but also someone provided from partner services).
>>>> Some
>>>> code (in all languages) apply business rules to this data and
>>>> transform
>>>> it in a some enrich information (information=data+Business rules).
>>>> Aggregating this data we build a final report to client that is
>>>> the
>>>> final product.
>>>> As said we are moving to SOA and we are identifying services and
>>>> aggregation of them. The area where DNA could be very useful is
>>>> solving
>>>> the problem of keeping track of information during time.
>>>> IOW we are asked to be able to provide not only current
>>>> information, but
>>>> also information related to a particular moment (remember
>>>> information
>>>> for us= data + business rules).
>>>> The system (or better a lot of service provider we are
>>>> considering part
>>>> of the system) haven't ability to keep data or bsiness rules
>>>> history, so
>>>> we have to store in some other places answer to be able to
>>>> retrive them
>>>> in future.
>>>> Here DNA could help us: the basic idea is to use JBossESB as
>>>> integration
>>>> layer where a MessageStore could store messages into DNA where
>>>> we can
>>>> apply different sequencers to extract information and organize
>>>> it for
>>>> our different future purpose.
>>>>
>>>> ok, a bit confused, but it's late night and I'm tired and
>>>> moreover the
>>>> project is on its start up.
>>>>
>>>> I'll try to explain better details regarding DNA very soon, as
>>>> soon as I
>>>> finished my design.
>>>>
>>>> bye
>>>> S.
>>>> _______________________________________________
>>>> dna-dev mailing list
>>>> dna-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/dna-dev
>>>
>>> _______________________________________________
>>> dna-dev mailing list
>>> dna-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/dna-dev
>>>
>>
>>
>>
>> --
>> Michael D Neale
>> home:
www.michaelneale.net
>> blog:
michaelneale.blogspot.com
>
>
--
Michael D Neale
home:
www.michaelneale.net
blog:
michaelneale.blogspot.com