[dna-dev] Several interesting InfoQ articles about JCR
Michael Neale
michael.neale at gmail.com
Thu Jun 12 19:45:18 EDT 2008
I guess I am thinking of the case of a large volume of small
"children" nodes - specifically. As you say, it can be a problem -
will DNA help with this at all?
On Fri, Jun 13, 2008 at 3:58 AM, Randall Hauch <rhauch at redhat.com> wrote:
> You're right that JCR handles heterogeneous data better than almost anything
> else, especially when the information structure changes/evolves over time.
>
> And I thought the InfoQ architecture was brilliant - use multiple
> independent JCRs for infrequently changing data, eliminating the need to
> create/maintain/scale a cluster. Very elegant and simple solution. And in
> this particular case, it doesn't really matter if there is a slight
> difference in content among the different machines during the push of new
> information to the independent repositories.
>
> But can you elaborate on your thought that JCR might not be useful for
> transactional data?
>
> IMO, JCR is useful in a lot of situations, and of course it is limited in
> others. Right now, the implementations don't do clustering or very large
> repositories well. Most impls also seem to be limited in the efficient
> handling of large numbers of children for any given node. Incorporation of
> information outside of JCR is also difficult, as it has to be done above JCR
> - although DNA will change this. But I'm not sure that frequently changing
> data is universally a limitation. Perhaps frequent additions of large
> volumes of data are a problem because you quickly get to volumes of data
> that are too large. Or frequent changes to data may be a problem if
> versioning is used, as it could quickly lead to unusable numbers of
> versions.
>
>
> On Jun 10, 2008, at 9:45 PM, Michael Neale wrote:
>
>> JCR seems to have a lot of traction I have noticed. Certainly seems to
>> be the default choice now for heterogenous data. And data is
>> increasingly heterogenous.
>>
>> I guess my only thoughts on it are its limitations: should JCR *not*
>> be used for transactional data - ie feeds of incoming data that change
>> often?
>>
>> On Wed, Jun 11, 2008 at 12:11 PM, Randall Hauch <rhauch at redhat.com> wrote:
>>>
>>> There have been a couple of recent articles on InfoQ about JCR and/or
>>> REST.
>>> In case you haven't seen them, they're all worth a good read.
>>>
>>> Interview with David Nuescheler, from Day Software:
>>> http://www.infoq.com/articles/nuescheler-jcr-rest
>>> InfoQ architecture and use of JCR:
>>> http://www.infoq.com/presentations/design-and-architecture-of-infoq
>>>
>>> Best regards,
>>> Randall
>>> _______________________________________________
>>> dna-dev mailing list
>>> dna-dev at 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
More information about the dna-dev
mailing list