Feature for handling getNextValue work in same transaction.
by Jeremy Whiting
Hi,
I am looking for feedback on changes to provide the ability for work
to be completed in a currently running transaction. For example when a
TableGenerator or SequenceGenerator is being used for generating unique
ids. The statements that select then update the db are executed in a
separate transaction.
There is a jira for this feature.
https://hibernate.atlassian.net/browse/HHH-8429
Attached to the jira is a diagram. See this link
https://hibernate.atlassian.net/secure/attachment/19534/hibernate-class-s...
This diagram shows what I currently have implemented. It shows the
existing classes and the new classes shaded in light blue. The methods
on a new class IsolationAware show how I've re-jigged most the
implementation from JtaTransaction to it's new ancestor IsolationAware.
A new concrete implementation of IsolationDelegate will negotiate the
work to be executed in the same running transaction.
The structure splits up the factory/transaction/delegate classes into
two groups. "same transaction" and "separate transaction". This has only
been done for JtaTransaction and the same will probably be necessary for
CMTTransaction as it also uses a separate transaction to complete work.
That has been left out to keep the diagram simple.
The option of using aggregation at the point where implementers of
TransactionImplementor are instantiated has been considered. Before too
much effort is expended coding I wondered what others thought is the
preferred way to implement this feature.
Jeremy
13 years
Hibernate Search compatibility with ORM 4.3
by Sanne Grinovero
There are some small changes in ORM 4.3 which are making HSearch
incompatible, while I'm trying to keep Search compatible with bith ORM
4.2.x and 4.3 series.
It's more complex than expected, so here is an update on what I'm doing:
# Shadowing of interfaces being moved to new packages
One change in particular is the move of certain Service interfaces to
a new package location, we discussed on IRC that a possible solution
would be to re-introduce a "shadow" interface: a patch to ORM
re-introducing the missing interfaces as deprecated extensions of the
new locations, so that projects compiling againts ORM 4.2 would still
work (not guaranteed as I'm exclusively shadowing the ones that I'm
needing for Search).
In practice this solution doesn't work: we use these interface also as
key for a lookup in the ServiceRegistry; obviously if the key is not
the same class definition we fail to retrieve the service.
At this point I tried to patch the ServiceRegistry itself to make it
handle specifically the backwards-friendly shadow interfaces, but it
looks like I can't do that as the method signature is locked-down:
public <R extends Service> R getService(Class<R> serviceRole) {
return (R) patchedGetService(); <---!!!
}
At this point I have to introduce the explicit casting or it won't
compile, but then also the cast will fail at runtime unless I revert
the parent/child relation of the shadow interface.
It's getting a bit messy and even the "patchedGetService" isn't very
nice I guess.
So on this I'm now looking for alternatives. We have two cases in
which the JtaPlatform is looked up, I could replace one such usage
with this alternative:
- TransactionManager transactionManager = getService(
JtaPlatform.class ).retrieveTransactionManager();
+ TransactionManager transactionManager = eventSource
+ .getTransactionCoordinator()
+ .getTransactionContext()
+ .getTransactionEnvironment()
+ .getJtaPlatform()
+ //.canRegisterSynchronization() <- TODO explore: possibly
a better option?
+ .retrieveTransactionManager();
In the second case I don't have an EventSource but I have a
SessionFactoryImplementor.. I'm not finding a similar path to get the
JtaPlatform without opening a temporary Session: anyone knows better?
Tia,
Sanne
13 years
HCANN release protocol
by Steve Ebersole
What is the proper way to release hibernate-commons-annotations? Do we
just use Maven release plugin?
13 years
[Validator] Applying constraints to property objects
by Gunnar Morling
Hi,
Yesterday George Gastaldi from the Forge team approached me regarding the
application of constraints to "wrapped" properties. Their situation is the
following:
...
@Size(min=3, max=10)
UIInput<String> name;
...
Here, UInput is some kind of UI component, wrapping the actual property
value. As is, validation of this property will fail since there is no
validator for applying @Size to UIInput (only for String).
A similar use case exists in JavaFX where one might want to apply
constraints to the FX *Property types:
...
@Min(5)
IntegerProperty count = new SimpleIntegerProperty(4);
...
Again, validation will fail out of the box, as no validator for applying
@Min to IntegerProperty exists (but for int/Integer).
How could this be solved? The following alternatives came to my mind:
a) Create and register validators for these wrapper types, e.g.
ConstraintValidator<Size, UIInput> etc.
Pro: Works with the existing APIs without modification
Con: Lots of code to write, either duplicating code or delegating to
(internal) implementation types; doesn't automatically benefit from new
built-in validators
b) Apply constraints to getters instead of fields:
IntegerProperty count = new SimpleIntegerProperty(4);
@Min(5)
int getCount() {
return count.getValue();
}
Pro: Works with the existing APIs without modification; benefits from any
newly added built-in validators
Con: There may be cases where there is no such getter, e.g. for parameter
validation
c) Provide an SPI which allows to plug in a custom "value processor"
implementation, retrieving the wrapped object and its "declared" type:
public interface ValidationValueProcessor {
Object getValidatedValue(Object source);
Type getDeclaredType(Type sourceType);
}
For the original example, the methods would return the name value and
String.class, respectively.
Note that validator resolution is done using the static type of a property,
so I think the original example above should be supported, but the
following should not as no validator for @Size/Object exists:
@Size(min=3, max=10)
UIInput<Object> name;
Pro: Benefits from any newly added built-in validators, allows directly
annotating "wrapped" properties, requires no implementation by the user
besides the ValidationValueProcessor
Con: new HV-specific (at least for the time being) SPI
I think a) creates prohibitively high efforts for the user/integrator, b)
lacks support for method constraints, so I think c) should be implemented,
possibly making this a spec SPI later on.
Does anyone have other preferences or alternatives? If you also think c)
makes most sense, do you have a good/better idea for the interface and
method names?
Thanks,
--Gunnar
13 years
Re: [hibernate-dev] [Validator] Applying constraints to property objects
by Gunnar Morling
(using correct list now)
2013/9/3 Hardy Ferentschik <hardy(a)hibernate.org>
>
>
>
>
> On 3 Sep 2013, at 15:58, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > Hi,
> >
> > Yesterday George Gastaldi from the Forge team approached me regarding the
> > application of constraints to "wrapped" properties. Their situation is
> the
> > following:
> >
> > ...
> > @Size(min=3, max=10)
> > UIInput<String> name;
> > ...
> >
> > Here, UInput is some kind of UI component, wrapping the actual property
> > value. As is, validation of this property will fail since there is no
> > validator for applying @Size to UIInput (only for String).
> >
> > A similar use case exists in JavaFX where one might want to apply
> > constraints to the FX *Property types:
> >
> > ...
> > @Min(5)
> > IntegerProperty count = new SimpleIntegerProperty(4);
> > ...
> >
> > Again, validation will fail out of the box, as no validator for applying
> > @Min to IntegerProperty exists (but for int/Integer).
> >
> > How could this be solved? The following alternatives came to my mind:
> >
> > a) Create and register validators for these wrapper types, e.g.
> > ConstraintValidator<Size, UIInput> etc.
> >
> > Pro: Works with the existing APIs without modification
> > Con: Lots of code to write, either duplicating code or delegating to
> > (internal) implementation types; doesn't automatically benefit from new
> > built-in validators
> >
> > b) Apply constraints to getters instead of fields:
> >
> > IntegerProperty count = new SimpleIntegerProperty(4);
> >
> > @Min(5)
> > int getCount() {
> > return count.getValue();
> > }
> >
> > Pro: Works with the existing APIs without modification; benefits from any
> > newly added built-in validators
> > Con: There may be cases where there is no such getter, e.g. for parameter
> > validation
> >
> > c) Provide an SPI which allows to plug in a custom "value processor"
> > implementation, retrieving the wrapped object and its "declared" type:
> >
> > public interface ValidationValueProcessor {
> > Object getValidatedValue(Object source);
> > Type getDeclaredType(Type sourceType);
> > }
>
>
> How would such a processor work? In particular how does an implementation
> decide whether the value needs to be unwrapped or just accessed directly?
I think an implementation would decide this by examining the declared type
of a property, parameter etc. E.g. the JavaFX Property processor would only
accept *Property typed elements and ignore all others. Probably there
should be another method "boolean accepts(Type declaredType)" which is
invoked by the engine for that purpose.
> Is there a need for configuring multiple processors?
>
Yes, I think so. So a user could work with wrapped types of different
kinds. Maybe we should even support nested wrapped elements such as
UIInput<StringProperty>. But this might be a second step.
> What other use case is there outside JavaFX?
>
The original use case is UIInput from Forge. Maybe other UI technologies
where one wants to apply validation to some kind of form object with UI
controls instead of a backing bean model.
--hardy
>
>
13 years
