-
Notifications
You must be signed in to change notification settings - Fork 228
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
Support multiple JpaDataStore
#2998
Conversation
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.
Looked over elide-core only so far.
@@ -151,6 +171,7 @@ public Object loadObject(EntityProjection projection, Serializable id, RequestSc | |||
|
|||
synchronized (dataStore) { | |||
Map<String, Object> data = dataStore.get(projection.getType()); | |||
cacheForRollback(projection.getType(), data); |
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.
I think we can remove the synchronized blocks in this class now that there is a read/write lock on the transaction
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.
Have removed the synchronized blocks.
* @param target the bean to copy to | ||
* @param cls the class | ||
*/ | ||
public static void copyProperties(Object source, Object target, Type<?> cls) { |
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.
Nice improvements over the clone in MultiplexWriteTransaction.
I think the build error is transient. I tried running the failing |
In order to support multiple transactional
JpaDataStore
in Spring theMultiplexManager
needed to be modified to process transactions last-in-first-out instead of first-in-first-out. After making this modification, a test was failing. The test was testing that the previously committed transaction on aHashMapDataStore
was being reversed by theMultiplexManager
. Reversing the order meant that the transaction on theHashMapDataStore
wasn't even being commited, however the data was still modified. The objects retrieved from theHashMapDataStore
are the same reference from the store, so any modifications to the store actually already modifies the data in the underlying store.In order to fix this the following things were done to the
HashMapDataStore
.ReadWriteLock
was introduced so write transactions need an exclusive lock when making modificationsMultiplexManager
does to reverse the transactionThe new
HashMapDataStoreTest#testShouldNotReadDirtyData
test demonstrates the issue and the fix.Description
JtaTransactionManager
is now supported@EnableJpaDataStore
annotation is added to make it easy to add and configure multipleJpaDataStore
. Allows configuring the entity manager, transaction manager or the managed classes.DataStoreBuilderCustomizer
andJpaDataStoreRegistrationsBuilderCustomizer
to allow customization of the autoconfiguration without needed to totally copy and paste the existing codes.MultiplexManager
now processes transactions last-in-first-out.HashMapDataStore
modified for data consistency.Motivation and Context
Makes it possible to have multiple transactional
JpaDataStore
in the same transaction. Makes the configuration ofJpaDataStore
easier.How Has This Been Tested?
Tested with unit and integration tests.
In particular the following were tested for Spring
JpaTransactionManager
and 2 xEntityManagerFactory
JtaTransactionManager
and 2 xEntityManagerFactory
The Atomikos
JtaTransactionManager
was used for the test.License
I confirm that this contribution is made under an Apache 2.0 license and that I have the authority necessary to make this contribution on behalf of its copyright owner.