jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Isolation level inconsistency.
Date Fri, 20 Jul 2007 17:02:25 GMT
On 7/20/07, Hendrik Beck (camunda) <hendrik.beck@camunda.com> wrote:
> > From: Alexandru Popescu ☀ [mailto:the.mindstorm.mailinglist@gmail.com]
> >
> > Hendrik I am afraid you are confusing the visibility over different
> > sessions (you are discussing about this one), and the transient state
> > inside the same session (which is the topic discussed in here).
>
> Arrgh, you could be right, Alexandru ;-) But I think it's more about the way we use it.
The way we use and share Sessions on the one hand but also the use cases we have. For example,
we don't really have long running transaction with JCR, as Ivan just mentioned about...
>

The fact that my app or yours are not using long-lived
sessions/transactions is not really relevant when discussing a spec
:-).
A spec should be clear about the usage scenarios and this is what I am
trying to accomplish this (even if it is in the form of: if you using
long-lived sessions then you need to do this and that....).
And this is extremely important if we think about the adoption and
future of the spec. We don't want to get yet another spec that is
missing important aspects or a spec that will need to be changed very
soon because it was not looking at enough scenarios (we have plenty of
such wrong examples and personally I would hate that the JCR one will
join those).

bests,
./alex
--
.w( the_mindstorm )p.

>
> > -----Original Message-----
> > From: Alexandru Popescu ☀ [mailto:the.mindstorm.mailinglist@gmail.com]
> > Sent: Friday, July 20, 2007 10:47 PM
> > To: users@jackrabbit.apache.org
> > Subject: Re: Isolation level inconsistency.
> >
> > On 7/20/07, Hendrik Beck (camunda) <hendrik.beck@camunda.com> wrote:
> > > > From: Alexandru Popescu ☀ [mailto:the.mindstorm.mailinglist@gmail.com]
> > > > I would really appreciate if somebody would post on this thread a
> > > > scenario in which the current behavior is proving helpful (and I have
> > > > in mind the scenario posted here: searching for a John and getting a
> > > > Joe instead -- frankly speaking I would be totally surprised in real
> > > > life if I would be looking for my wife and getting somebody else
> > > > instead :-) ).
> > >
> > > Uhm, which behaviour do you want to see? In one of our projects we use
> > JCR to enrich our business objects (like Products for a web shop) with
> > content data. This content is shown on the web site. The employees edit
> > this content concurrently with an application, every one on its one. They
> > make changes to different products and when they are finished, they
> > persist these changes by invoking save(). As long as they didn't do that,
> > the people who search and browse the web site only see the persistant
> > state, i.e. the data that is really stored "forever". It would be crucial
> > if people would see all the transient states on the websites and
> > furthermore it would be wrong. Invoking save is something like saying "ok,
> > now I am finished, now I want everybody else to see my changes".
> > >
> > > On the other hand as long as they haven't pressed save(), they still
> > want to see their own changes, that's also obvious. But they should only
> > see their own changes.
> > >
> > > So for me the only thing that could be a problem is, that an employee
> > didn't press save() and wants to search the repository. In that case they
> > could get results that differ from their local changes. But I would say,
> > if there are any good technical (Jackrabbit-) reasons, that's ok. Then
> > they just have to save their changes and then everything's right again.
> > But in our use cases that doesn't really happen. People rather use the
> > search to find the nodes they want to change. Then they select these
> > nodes, change them, press save() and that's it.
> > >
> > > Actually I thought that's one of the most common use cases JCR is used
> > for but apparanty not?!
> > >
> >
> > Hendrik I am afraid you are confusing the visibility over different
> > sessions (you are discussing about this one), and the transient state
> > inside the same session (which is the topic discussed in here).
> >
> > bests,
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Alexandru Popescu ☀ [mailto:the.mindstorm.mailinglist@gmail.com]
> > > > Sent: Friday, July 20, 2007 3:18 PM
> > > > To: users@jackrabbit.apache.org
> > > > Subject: Re: Isolation level inconsistency.
> > > >
> > > > On 7/20/07, Julian Reschke <julian.reschke@gmx.de> wrote:
> > > > > Hendrik Beck (camunda) wrote:
> > > > > > One more thing I want to say:
> > > > > >
> > > > > > "again you're proposing a major change to JCR."
> > > > > >
> > > > > > "Maybe it's just me, but I have no idea how that could be
> > implemented
> > > > > > efficiently, *in
> > > > > > particular* if you don't have the luxury to develop that
> > functionality
> > > > from
> > > > > > scratch."
> > > > > >
> > > > > >
> > > > > > 1) In my eyes the public review is there to give any feedback,
to
> > > > discuss
> > > > > > everything and to make proposals, whether they are major changes
> > or
> > > > just
> > > > > > little remarks.
> > > > >
> > > > > That's right. The point I was trying to make (and apparently failed)
> > was
> > > > > that this is a major change to *JCR 1.0*.
> > > > >
> > > > > > 2) I wouldn't agree that discussions about implementation details
> > > > should be
> > > > > > part of a public review of a specification. Sure we should keep
an
> > eye
> > > > on
> > > > > > the implementation, it has to be done at some point. But, we
talk
> > > > about JCR,
> > > > > > not Jackrabbit. The JCR specification shouldn't take care about
> > > > > > implementation details of one product (Jackrabbit), but it should
> > find
> > > > the
> > > > > > best way to make the specification according to people's needs
and
> > > > > > requirements.
> > > > >
> > > > > Actually, I wasn't talking about Jackrabbit either.
> > > > >
> > > > > If JCR 2.0 adds requirements that are unlikely to be implemented,
> > that's
> > > > > IMHO a problem. Either you'll end up with no implementations, or
> > with
> > > > > broken implementations (with respect to that feature).
> > > > >
> > > > > Best regards, Julian
> > > > >
> > > > >
> > > >
> > > > I agree with both you comments here. However, I do feel that the OP
> > > > may be right (I confess that I was not facing this situation so far,
> > > > but this is probably because my app is a bit different).
> > > >
> > > > I would really appreciate if somebody would post on this thread a
> > > > scenario in which the current behavior is proving helpful (and I have
> > > > in mind the scenario posted here: searching for a John and getting a
> > > > Joe instead -- frankly speaking I would be totally surprised in real
> > > > life if I would be looking for my wife and getting somebody else
> > > > instead :-) ).
> > > >
> > > > bests,
> > > >
> > > > ./alex
> > > > --
> > > > .w( the_mindstorm )p.
> > >
> > >
>
>
Mime
View raw message