Replies: 1 comment
-
Here is the reason for not sharing auto-incrementing using The Entity framework is designed to be thread-safe by default, changing immutable data in one shot. Check out the generated Updaters and how a single field change cause entire immutable data object change. If you need to control concurrency further, I think the team recently added to the Serializer sister project some of the ideas discussed here In a way, the entity framework implements with code generations two upcoming/missing Java features:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I recently learned we have layered entities and as part of this concept a ready to use versioning layer.
Firstly, it looks like in case I use this on the dataroot object I can (in theory) create a complete versioned history of my object graph (something like a "temporal database") which sounds great, e.g. for timetravelling the data or simple datawarehousing within the application scope.
Still a few points I am confused about.
I don't understand fully what this warning means:
The documentation of layered entities talks about the logic layer and reads:
I think I understand the versioning aspect. For each entity creation there is an version with id 1 and then successively for each update (is this a store of an object in the object graph operation ?) there are appended copied versions with id 2, 3,...
Now I have different versions, but what about locking? There is
synchronized
keyword, Mutex Locking for Spring Boot or the new Feature Request: Adding Synchronization and Locks via AspectJWhat I am interested in is a way to do it in CDI / Jakarta EE. It should be possible to create a
@Read / @Write
annotation like in Sping Boot?But, how does this add up to the layered entities? To prevent multiple users changing the same part of the object, e.g. a name, seems necessary.
Some questions about the generator:
Comparing with the XDEV Spring-Data-Eclipse-Store (SDES): thinking in the eclipsestore object graph way - does the layered entities approach basically tries to solve the same problem as SDES does (but without the working copies)?
I am trying to understand a few concepts here related to concurrency, locking (pessimistic / optimistic) and versioning...
Is it possible to provide a more complete example addressing my questions?
The https://github.com/eclipse-store/store/tree/main/examples/layered-entities seems a bit too small to me, e.g. there are no Creator / Updator classes included and how is it used with the store?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions