[
https://issues.apache.org/jira/browse/OAK-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519422#comment-17519422
]
Olivier Jolit edited comment on OAK-8917 at 4/8/22 8:36 AM:
------------------------------------------------------------
Indeed {{select datname, datcollate from pg_database;}} gives a {{en_US.UTF8}}
collation. Although I cannot change it and try if this solves this issue as we
gave up on oak 2 years ago due to this issue.
While reading the current documentation page this is not clear for me that this
collation doesn't match the requirements (the differences explained in
[https://dba.stackexchange.com/questions/240930/postgresql-difference-between-collations-c-and-c-utf-8]
make it clearer though, but in my opinion this should be expanded in the
documentation as it is quite complex and one would expect that common
collations are valid).
If this collation requirement is not present in the installation it would be
great if oak could at least detect it and fail with a clearer error message.
was (Author: olivier.jolit):
Indeed `select datname, datcollate from pg_database;` gives a `en_US.UTF8`
collation. Although I cannot change it and try if this solves this issue as we
gave up on oak 2 years ago due to this issue.
While reading the current documentation page this is not clear for me that this
collation doesn't match the requirements (the differences explained in
[https://dba.stackexchange.com/questions/240930/postgresql-difference-between-collations-c-and-c-utf-8]
make it clearer though, but in my opinion this should be expanded in the
documentation as it is quite complex and one would expect that common
collations are valid).
If this collation requirement is not present in the installation it would be
great if oak could at least detect it and fail with a clearer error message.
> Thousands ConflitException on .createRepository()
> -------------------------------------------------
>
> Key: OAK-8917
> URL: https://issues.apache.org/jira/browse/OAK-8917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.24.0
> Reporter: Olivier Jolit
> Priority: Minor
> Attachments: effective-pom.xml, output
>
>
> I use OAK in my Spring Boot application to store user content (bookmarks).
> Users will write to OAK via REST calls.
> So I create a repository (in a Spring Bean) on my application startup with:
> {code:java}
> public OakBookmarkService() {
> RDBDocumentNodeStoreBuilder.newRDBDocumentNodeStoreBuilder()
>
> .setRDBConnection(RDBDataSourceFactory.forJdbcUrl("jdbc:postgresql://" + host
> + ":" + port + "/" + db + "?currentSchema= " + schema, user, password,
> sqlDriverClassName)).build()
> SecurityProvider securityProvider = new
> BookmarksSecurityProvider(rolesProvider);
> ThreeWayConflictHandler threeWayConflictHandler = new
> BookmarkConflictHandler();
> repository = new Jcr(new
> Oak(store)).with(securityProvider).with(threeWayConflictHandler).createRepository();
>
> ...
> }{code}
> The issue I have is that this creation of the repository throws thousands of
> ConflitExceptions like:
> {code:java}
> The node 1:/jcr:system already existed in revision
> r170631ac223-0-1 (older than base r17063a941e2-0-1), commit revision:
> r17063a95314-0-1 {code}
> Which prevent my application from starting.
> Deleting all the tables in my PostgreSQL database between each startup of my
> server fixes this issue but is obviously not expected. So it seems to me that
> OAK tries to recreate the default nodes in the database even though they
> already exist.
> I see in the documentation
> ([https://jackrabbit.apache.org/oak/docs/construct.html]) that I need to
> logout and dispose of the node store after each use. Do I have to do this
> when the server stops ? How to ensure this is done even when the server
> crashes in this case ?
> Or should I create the node store at the beginning of each REST call and
> dispose of it at the end every time ? For now I only create a session and
> close it for each call and am assuming creating the store each time is too
> expensive.
> Also, my conflict handler (that always returns Resolution.OURS for now) does
> not seem to be called in this scenario, which surprises me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
