R: distributed transactions

[Ancona Francesco]

Yes, i know that we can manage in our application logic inconsistent 
situations, but we'd like to know the rational behind these intentional design 
constraint.
With transaction it's obvious that coding should be easier.

Thanks in advance

-Messaggio originale-
Da: Julian Reschke [mailto:julian.resc...@gmx.de] 
Inviato: lunedì 18 aprile 2016 17:41
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone ; Morelli Alessandra 

Oggetto: distributed transactions

On 2016-04-18 17:22, Ancona Francesco wrote:
> I try explain the case.
>
> We know that OAK doesnt'support Transaction, so the following should 
> be the JCR implementation:
>
> http://www.day.com/specs/jcr/2.0/10_Writing.html
>
> When i use session write-methods, i can execute a sequence of session 
> methods (example add nodes) but only when i use save method i persist 
> the changes.
>
> Instead when i use Workspace-Write Methods (example 
> VersionManager.checkin, checkout, checkpoint, restore, restoreByLabel, 
> merge, cancelMerge, doneMerge, createActivity , removeActivity and 
> createConfiguration), for each action i persist on the workspace.
>
> So, imagine a use case in which i must create a version of a document 
> and  save it in my repository in atomic way; if the first phase works 
> but the second one is KO, we have inconsistent data: the document has 
> a new version but is not saved.
>
> *Which kind of workaround do you suggest to solve this problem ?*
>
> Thanks in advance,
>
> best regards

OK, so first of all this has *nothing* to do with the RDB persistence in 
particular; it applies to all persistence modes of OAK.

Furthermore, I don't agree this is a "major" problem. Yes, there are certain 
sequences that can't be done atomically; this is intentional design constraint 
of Oak (of now). It's not entirely clear to me why this isn't something that 
application logic can't deal with.

Best regards, Julian


 
 

This footnote confirms that this email message has been scanned by PineApp 
Mail-SeCure for the presence of malicious code, vandals & computer viruses.

distributed transactions

[Julian Reschke]

On 2016-04-18 17:22, Ancona Francesco wrote:

I try explain the case.

We know that OAK doesnt'support Transaction, so the following should be
the JCR implementation:

http://www.day.com/specs/jcr/2.0/10_Writing.html

When i use session write-methods, i can execute a sequence of session
methods (example add nodes) but only when i use save method i persist
the changes.

Instead when i use Workspace-Write Methods (example
VersionManager.checkin, checkout, checkpoint, restore, restoreByLabel,
merge, cancelMerge, doneMerge, createActivity , removeActivity and
createConfiguration), for each action i persist on the workspace.

So, imagine a use case in which i must create a version of a document
and  save it in my repository in atomic way; if the first phase works
but the second one is KO, we have inconsistent data: the document has a
new version but is not saved.

*Which kind of workaround do you suggest to solve this problem ?*

Thanks in advance,

best regards


OK, so first of all this has *nothing* to do with the RDB persistence in 
particular; it applies to all persistence modes of OAK.


Furthermore, I don't agree this is a "major" problem. Yes, there are 
certain sequences that can't be done atomically; this is intentional 
design constraint of Oak (of now). It's not entirely clear to me why 
this isn't something that application logic can't deal with.


Best regards, Julian

R: critical question about oak: RDBMS and distributed transaction

[Ancona Francesco]

I try explain the case.

We know that OAK doesnt'support Transaction, so the following should be the JCR 
implementation:



http://www.day.com/specs/jcr/2.0/10_Writing.html

[cid:image003.jpg@01D19996.DE408710]



When i use session write-methods, i can execute a sequence of session methods 
(example add nodes) but only when i use save method i persist the changes.

Instead when i use Workspace-Write Methods (example VersionManager.checkin, 
checkout, checkpoint, restore, restoreByLabel, merge, cancelMerge, doneMerge, 
createActivity , removeActivity and createConfiguration), for each action i 
persist on the workspace.



So, imagine a use case in which i must create a version of a document and  save 
it in my repository in atomic way; if the first phase works but the second one 
is KO, we have inconsistent data: the document has a new version but is not 
saved.



Which kind of workaround do you suggest to solve this problem ?



Thanks in advance,

best regards







-Messaggio originale-
Da: Julian Reschke [mailto:julian.resc...@gmx.de]
Inviato: giovedì 14 aprile 2016 18:05
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone ; Morelli Alessandra 

Oggetto: Re: critical question about oak: RDBMS and distributed transaction



On 2016-04-14 17:24, Ancona Francesco wrote:

> Hi,

>

> thanks for rdbms help. I managed to run my application also with

> postgres and Oracle. My wrong has been that default installation

> doesn't work; we need to set another collation. (in detail collation

> C)

>

> Can i suggest to add these details to the documentation ?



The only documentation right now is in RDBDocumentStore's javadoc, and that 
does mention it.



> Now we have an other problem.

>

> We found that distributed transactions are not supported in OAK. This

> could be a problem when we need to aggregate different kind of

> services (our database and ecm services): so our data could be not

> choerent in specific situations.

>

> Besides we noticed that there is a major issue opened in 2013 but not

> closed.



Specifically?



> So i point out 3 question

>

> 1.Is there a roadmap or an indicative date to solve this issue?

>

> 2.Which kind of workaround do you suggest to solve the problem now ?

>

> 3.Do you know if adobe oak built-in product has implemented the

> distributed transactions ?



AFAIU, Oak wasn't designed with distributed transactions in mind, nor is it 
currently used that way. I'm not aware of any plans to change that...



Best regards, Julian









This footnote confirms that this email message has been scanned by PineApp 
Mail-SeCure for the presence of malicious code, vandals & computer viruses.

[ANNOUNCE] Apache Jackrabbit Oak 1.5.1 released

[Davide Giannella]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.5.1 The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:


Release Notes -- Apache Jackrabbit Oak -- Version 1.5.1

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Apache Jackrabbit Oak 1.5.1 is an unstable release cut directly from
Jackrabbit Oak trunk, with a focus on new features and other
improvements. For production use we recommend the latest stable 1.4.x
release.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.5.1
-

Technical task

[OAK-4156] - RDBConnectionHandler: add logging when getting the
connection takes long

Bug

[OAK-4135] - Test failure:
org.apache.jackrabbit.j2ee.TomcatIT.testTomcat
[OAK-4148] - RAT plugin complains about derby files
[OAK-4155] - oaj.oak.spi.security.authentication.credentials not
exported

Improvement

[OAK-2392] - [DocumentMK] Garbage Collect older revisions of
binary properties in main document
[OAK-4095] - Include timestamp in journal log entries
[OAK-4108] - Reduce logging from JournalGarbageCollector
[OAK-4130] - Simplify IdentifierManager.getReferences
[OAK-4136] - release profile in maven
[OAK-4152] - Expose the index path to IndexEditor
[OAK-4159] - Expose an option in Oak class to enable failing of
commit upon missing index editor provider
[OAK-4160] - Expose type property for ReferenceEditorProvider
[OAK-4163] - LastRevRecoveryAgent: improve startup diagnostics
[OAK-4164] - Expose path stats for Lucene index

New Feature

[OAK-4144] - Expose PropertyIndex stats

Task

[OAK-4076] - Benchmark to measure affect of number of indexes on
uuid lookup performance
[OAK-4132] - JaasConfigSpiTest fails intermittently with missing
LoginModule exception

In addition to the above-mentioned changes, this release contains
all changes included up to the Apache Jackrabbit Oak 1.4.x release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by SHA1 and MD5 checksums and a PGP
signature that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
http://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

For more information, visit http://jackrabbit.apache.org/oak

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.30

[Alex Parvulescu]

[X] +1 Release this package as Apache Jackrabbit Oak 1.0.30

alex

On Mon, Apr 18, 2016 at 3:31 PM, Dominique Jaeggi  wrote:

> A candidate for the Jackrabbit Oak 1.0.30 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.30/
>
> The release candidate is a zip archive of the sources in:
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.30/
>
> The SHA1 checksum of the archive is
> 6dac043ecf89f44a2fc7e4a65dfef1e39692d43c.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> $ sh check-release.sh oak 1.0.30
> 6dac043ecf89f44a2fc7e4a65dfef1e39692d43c
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.0.30.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.30
>
> [ ] -1 Do not release this package because...
>
> My vote is +1.
>
> Thanks
> dom.
>

[RESULT][VOTE] Release Apache Jackrabbit Oak 1.5.1

[Davide Giannella]

Hello Team,

the vote passes as follows:

+1 Davide Giannella
+1 Dominique Jaeggi
+1 Julian Reschke

Thanks for voting. I'll push the release out.

-- Davide

[VOTE] Release Apache Jackrabbit Oak 1.0.30

[Dominique Jaeggi]

A candidate for the Jackrabbit Oak 1.0.30 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.30/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.30/

The SHA1 checksum of the archive is
6dac043ecf89f44a2fc7e4a65dfef1e39692d43c.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

$ sh check-release.sh oak 1.0.30 6dac043ecf89f44a2fc7e4a65dfef1e39692d43c

Please vote on releasing this package as Apache Jackrabbit Oak 1.0.30.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.0.30

[ ] -1 Do not release this package because...

My vote is +1.

Thanks
dom.

Re: API to get all revisions affecting a NodeDocument

[Robert Munteanu]

On Mon, 2016-04-18 at 07:16 +, Marcel Reutegger wrote:
> Hi,
> 
> NodeDocument.getAllChanges() gives you an Iterable over
> all changes (including non-committed) on a document. If you
> are only interested in committed changes you have to filter
> them with a check on the same document isCommitted(rev)

I'll have a look, thanks. I initially missed it since I was looking at
public methods only and this one is package-private.

Robert



> 
> Regards
>  Marcel
> 
> On 14/04/16 14:44, "Robert Munteanu" wrote:
> 
> > 
> > Hi,
> > 
> > For a NodeDocument I'd like to know which revisions it is linked
> > to  (
> > in order to infer the commits ).
> > 
> > I've looked at NodeDocument#getLastRev ( but not all documents have
> > the
> > _lastRev field defined ). I've also tried to to use
> > DocumentNodeStore#getHeadRevision , but the revision I get doesn't
> > work
> > with NodeDocument#getCommitRootPath .
> > 
> > Is there an API for retrieving the revisions that affect a
> > NodeDocument?
> > 
> > Thanks,
> > 
> > Robert

Re: API to get all revisions affecting a NodeDocument

[Marcel Reutegger]

Hi,

NodeDocument.getAllChanges() gives you an Iterable over
all changes (including non-committed) on a document. If you
are only interested in committed changes you have to filter
them with a check on the same document isCommitted(rev)

Regards
 Marcel

On 14/04/16 14:44, "Robert Munteanu" wrote:

>Hi,
>
>For a NodeDocument I'd like to know which revisions it is linked to  (
>in order to infer the commits ).
>
>I've looked at NodeDocument#getLastRev ( but not all documents have the
>_lastRev field defined ). I've also tried to to use
>DocumentNodeStore#getHeadRevision , but the revision I get doesn't work
>with NodeDocument#getCommitRootPath .
>
>Is there an API for retrieving the revisions that affect a
>NodeDocument?
>
>Thanks,
>
>Robert