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