On 9.6.2017 13:10, Niclas Hedhman wrote:
How about the (to me) difference between "Service Activation" (singleton,
outside view) and "Service Mixin Lifecycle" (typically resource
initialization that each mixin manage on its own)? Did you figure out the
detailed semantics here as well?
I took a bit different approach in C# than what was in Java back in that
time, I think it was originally your suggestion:
Each fragment class can declare any amount of methods, which are
annotated with annotations recognized by Polygene.
If such method declares any parameters, they all must be injectable.
For example, if fragment class has any methods with [Activation]
annotation, these methods will be executed when service is activated.
The passivation works similarly for [Passivation] annotation.
Similarly I have [Initialize] annotation, those methods will be executed
every time instance of fragment has been created and all fields injected.
Typically, instance of fragment is created only once during composite
lifecycle, but concurrent access may cause additional creations.
Then I have [Prototype] annotation, those methods will be executed when
the composite factory transforms from prototype phase to actual
composite phase.
So, the [Prototype] methods will be executed at most once during
composite lifecycle.
Note that indeed composite factory does not create copy when
"Instantiate" method is called - composite instance internally goes from
prototype mode to instance mode.
So far, I've been able to solve all the problems using that approach.
The *earliest* point that user-code may execute is [Inititalize]
annotation, and I take care of setting up the composite state and all
fragment instance pools etc before that.
But also, since C# has concept of "property" within language itself, I
do not have "Property" interface - properties that are left abstract
(their getter and setter both lack implementation in any fragment type)
are the ones that the runtime will figure out to be manageable by the
runtime itself, and which are part of the composite state.
Their property type (return type of getter and parameter type of setter)
is the type which I think in Java is 'T' of 'Property<T>' interface.
This difference in programming language might have simplified and solved
some issues that you guys are currently facing in Java.
Cheers
On Fri, Jun 9, 2017 at 4:10 PM, Stanislav Muhametsin <
[email protected]> wrote:
FWIW, I really had to sit down and think a lot about all concurrency etc
issues in C# version of Polygene.
There, I am using CompareExchange-based algorithms to simulate state
machine:
0 - Initial
1 - Activating
2 - Active
3 - Passivating
4 - Passive
Legal transitions are:
0 -> 1 (Initial activation)
1 -> 2 (Activation successful)
1 -> 4 (Exception in activation)
2 -> 3 (Starting to passivate)
3 -> 4 (Passivation successful (even if exception))
4 -> 1 (Re-activating)
That way, I can also detect recursive calls within activation/passivation
methods (when state is 1 or 3), which helps avoid some nasty
StackOveflowExceptions and other inconsistencies.
I've got things to work very nicely even in very large and complex
applications, where service activations can cascade multiple layers down.
On 09/06/2017 05:50, Niclas Hedhman wrote:
I found another bad side-effect of the current Service Activation.
The issue I have is that a Private Mixin is not seen by the Service
Activation system, and activateService() is never called.
So, I thought that I simply do a delegation from the public Mixin to the
private one;
@This
private MyPrivate parts;
public void activateService()
throw Exception
{
parts.activateService();
}
Anybody cares to guess what Exception I got?? ;-)
