Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MODE-650: Initial CMIS connector implementation #704

Closed
wants to merge 94 commits into from

Conversation

okulikov
Copy link
Member

This pull-request is just for review, and is not ready for merging.

okulikov and others added 30 commits February 18, 2013 15:40
… options.

The garbage collection options can now be specified in the repository
configuration. Each repository registers its own garbage collection
processes with a named thread pool, and these processes are stopped
when the repository is shut down.
…stem

Added the garbage collection configuration attributes to ModeShape's
XSD schema and subsystem, and added a unit test that verifies the
attributes are read correctly.
Added property converter
Update properties during document modification
Migrate to integration tests
… simultaneously from multiple threads. The solution was to add an additional method to JcrSession#PreSave and which is executed only after Infinispan locks are obtained on the changed nodes.
Made several improvements to the recent changes that add validation
of SNS *after* locks were obtained.
Added a new specialization of WorkspaceCache called
TransactionWorkspaceCache that is used in place of WorkspaceCache
any time a ReadOnlySessionCache or WritableSessionCache is used
during the scope of a running user transaction.

Normally, each RepositoryCache instance has for each workspace a
single WorkspaceCache instance shared by all sessions. However, in
the case of a session is running within a user transaction, it is
possible for the session (or other sessions that are also participating
in the same user transaction) to persist node changes in the document
store but to not commit the transaction. This means that such
persisted-but-not-committed node representations should be visible to
the sessions running within the transaction but should not be visible
to sessions outside of the transaction. Because the shared
WorkspaceCache lazily loads the requested nodes using the transactional
scope of the requestor, this means that the WorkspaceCache may load
these persisted-but-not-committed node representations and make them
available to other sessions (outside the transaction boundary) and
thereby leaking transactionally-scoped data. Similarly,
a WorkspaceCache that already has the persisted-and-committed node
representations from other sessions will expose those already-cached
forms to sessions running within the transaction, thereby causing
some of the sessions in the same user transaction to not see the
transactionally-scoped (e.g., persisted-but-not-committed) changes.

Therefore, such sessions running within user transactions need a
transactionally-scoped WorkspaceCache instance rather than sharing
the commont WorkspaceCache instance. However, the ModeShape
infrastructure is not set up to handle lots of WorkspaceCache instances
for the same workspace, so we have to be careful about any
transaction-specific caches.

This new design changes the AbstractSessionCache to maintain the original
reference to the real (shared) WorkspaceCache, but to also have another
WorkspaceCache reference that may change (depending upon whether there
is a current user transaction) to a transient TransactionalWorkspaceCache
instance specific to the transaction.

Originally, I tried to have the TransactionalWorkspaceCache do no
caching whatsoever, but this caused problems within the
WritableSessionCache's persistChanges logic, which needs access to
the persisted representation of the node prior to when each changed
node was actually changed. So, the TWC simply uses an in-memory
ConcurrentHashMap. (The alternative was to use another Infinispan
cache such as the one used for the shared workspace caches, but this
would dramatically increase the complexity of the system and would
require an additional cache container configured with different settings
than the normal workspace caches and to use a different naming
convention.)

Several new test cases were added to verify that multiple sessions
within the same user transaction do indeed all see the same
transactionally-scoped data, while other sessions that are outside
of the user transaction do indeed not see any of the transactionally-
scoped changes until commit occurs.
Other fixes for MODE-1819 actually fixed the problem, while this
change only adds test cases and test dependencies on Atomikos to
verify the expected behavior now works. Also added similar tests
that use the JBoss Transactions library.
…written strings are always UTF-8 encoded and added UTF-8 as an explicit response header.
…nd also to generate full links when displaying the contents of folders.
Null check in case the node no longer exist in the cache.
… of the same node in a session

Fix the issue by making sure that nodeTypes with the same name is actually updated properly in the cache.
Before this fix, when a change was made via a WritableSessionCache,
any changes persisted to the store were also used to directly purge
any previously-cached node representations from the corresponding
WorkspaceCache. Thus, when the RepositoryCache received the changes,
it simply forwarding them to all workspaces except the one in which
the changes originated.

However, in a clustered environment, the changes originate on one
process and are sent to all other processes. The logic described
above works fine in the same process in which the changes originated,
but it doesn't correctly propagate the changes in the other processes.

The fix was pretty simple: determine if the changes came from the same
process. If so, the use the current logic. If not, always forward the
changes to all WorkspaceCache instances.

I also modified the ClusteredRepositoryTest to look in process A for
nodes changed in process B. This failed before the logic was fixed,
and now works with the fix.
@vasilievip
Copy link

Oleg, are files under connectors/modeshape-connector-cmis/src/main/resources required for connector to function properly?

@okulikov
Copy link
Member Author

Ivan, those files are used for running tests

--Oleg

2013/3/29 vasilievip notifications@github.com

Oleg, are files under
connectors/modeshape-connector-cmis/src/main/resources required for
connector to function properly?


Reply to this email directly or view it on GitHubhttps://github.com//pull/704#issuecomment-15642591
.

@vasilievip
Copy link

I've just deleted those files and tests are working just fine. Also there are minor changes in code. Will attach patch to the issue.

}, null);

registry.registerNamespace(CmisLexicon.Namespace.PREFIX, CmisLexicon.Namespace.URI);
importTypes(session.getTypeDescendants(null, Integer.MAX_VALUE, true), nodeTypeManager);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Import types must also import namespaces

@vasilievip
Copy link

Oleg, sorry for confusion, there are 2 patches:
minor_changes.patch 31/Mar/13 12:59 PM
minorchanges.patch 29/Mar/13 7:53 PM

typeManager.registerNodeTypes(nodeDefs, true);
}

private int getJcrType(PropertyType propertyType) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be moved to helper "Properties"

@okulikov
Copy link
Member Author

okulikov commented Apr 1, 2013

Ivan, can you generate patch once again? I mean from the current stage. I
think I'v applied latest patch and can't now apply the second patch/

2013/4/1 vasilievip notifications@github.com

Oleg, sorry for confusion, there are 2 patches:
minor_changes.patch 31/Mar/13 12:59 PM
minorchanges.patch 29/Mar/13 7:53 PM


Reply to this email directly or view it on GitHubhttps://github.com//pull/704#issuecomment-15709773
.

@vasilievip
Copy link

Yes, let me merge first

@okulikov
Copy link
Member Author

okulikov commented Apr 1, 2013

I think I merged successfuly, please check now :)

2013/4/1 vasilievip notifications@github.com

Yes, let me merge first


Reply to this email directly or view it on GitHubhttps://github.com//pull/704#issuecomment-15709960
.

@vasilievip
Copy link

just supplied another patch, please try to apply

@okulikov okulikov closed this Apr 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants