[
https://issues.apache.org/jira/browse/IGNITE-16229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-16229:
-----------------------------------------
Fix Version/s: 3.0.0-alpha5
(was: 3.0.0-alpha4)
> Improve unmarshalling of immutable containers in the User Object
> Serialization component
> ----------------------------------------------------------------------------------------
>
> Key: IGNITE-16229
> URL: https://issues.apache.org/jira/browse/IGNITE-16229
> Project: Ignite
> Issue Type: Improvement
> Components: networking
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> At the moment, we support just one type of immutable containers
> (singletonList), but we'll probably want to support other types like
> List.of(), Set.of() and so on.
> Immutable built-in containers pose a challenge: on the one hand, they can
> participate in cycles and hence need to be read in two phases (instantiate,
> store reference, fill), but on the other hand, they cannot be modified after
> instantiation.
> Right now, we implemented a hack: we still read immutable containers in two
> phases, but for filling them we have a custom code that breaks their
> 'immutability' invariant and pushes the values by force via reflection to
> fill such containers. It seems to work, but it's ugly and potentially
> dangerous (as we are violating the immutability invariant).
> There is another possibility.
> # Handle all the values that are not built-in immutable containers in the
> same way they are handled now
> # For immutable containers, during instantiation phase, create mutable
> placeholders instead of the immutable container instances themselves
> # Such placeholders need to track the slots of other objects in the graph
> that reference them
> # They are filled normally on the 'fill' phase
> # After the graph is read into memory, it consists of (mainly) normal
> objects and placeholders; the placeholders need to be resolved and replaced
> with proper immutable container values
> # It is impossible to create a cycle of immutable containers (without using
> hacks like Reflection), so we can find connectivity components of the graph
> (each of such component will be a tree) and then instantiate immutable
> containers from placeholders in the leaf-to-root order
> # Placeholders need to be replaced with the instantiated immutable
> containers in the graph; here, the knowledge about the set of slots which
> reference a placeholder (mentioned in item 3) will be useful
> # If we encounter a cycle comprised completely of immutable containers (such
> cycle can only be creafted using some sort of a hack), we can either fail
> with an exception or use a hack (reflection) to forge just one connection of
> the cycle.
> This is a hybrid approach of
> * always having 'real' objects in the graph - which is not realistic when we
> have immutable containers
> * and always constructing a graph of placeholders first and then turning
> them into real objects (this is what Spring does with Bean Definitions and
> then Beans) - which seems to incur too much overhead, especially having in
> mind that most of the objects are not immutable containers and hence do not
> need placeholders to represent them in the intermediate graph
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
