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
Conversation
… 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.
…the columnName and propertyName are null.
… 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.
…, JDBC cache store
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.
Oleg, are files under connectors/modeshape-connector-cmis/src/main/resources required for connector to function properly? |
Ivan, those files are used for running tests --Oleg 2013/3/29 vasilievip notifications@github.com
|
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); |
There was a problem hiding this comment.
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
Oleg, sorry for confusion, there are 2 patches: |
typeManager.registerNodeTypes(nodeDefs, true); | ||
} | ||
|
||
private int getJcrType(PropertyType propertyType) { |
There was a problem hiding this comment.
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"
Ivan, can you generate patch once again? I mean from the current stage. I 2013/4/1 vasilievip notifications@github.com
|
Yes, let me merge first |
I think I merged successfuly, please check now :) 2013/4/1 vasilievip notifications@github.com
|
just supplied another patch, please try to apply |
This pull-request is just for review, and is not ready for merging.