11:01 a.m.
Hi,
When talking to people about OGM, there is always that awkward moment when
you need to explain that TX demarcation is required also for
non-transactional data stores.
While it makes sense for our purposes (we use the "TX cycle" to optimise
the work sent to the backend etc.), I can understand people who find that
odd API-wise. So I was thinking about how this could be improved.
When it comes to CDI, a more "neutral" annotation (and a portable extension
examining it) than @Transactional could be helpful:
@UnitOfWork
public void saveOrderAndCustomer(Order order, Customer customer) {
session.persist( order );
session.persist( customer );
}
By means of the @UnitOfWork annotation it would be expressed that the
entire method should run as one "transaction". This also could be used to
specify an error handler for our new API to be applied for this unit of
work:
@UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
public void saveOrderAndCustomer(Order order, Customer customer) { ... }
In non-managed environments, Java-8-style Lambda expressions could be
leveraged nicely to achieve the same:
session.runUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
};
This should feel much nicer to e.g. users of the MongoDB backend than
invoking session.getTransaction().begin()/commit(). It also plays greatly
together with the error handling stuff:
session.buildUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
} )
.onFailedGridDialectOperation( context -> {
// e.g. log failed op
return ErrorHandlingStrategy.ABORT;
} )
.onRollback( context -> {
// e.g. log applied ops
} )
.run();
Of course something equivalent could be done for Java 7, but it'd probably
look not as concise.
Any thoughts?
Cheers,
--Gunnar
11:13 a.m.
Did you consider that the existing definition of "Transaction
boundaries" can have different levels of isolation and guarantees,
depending on how the underlying components are configured?
I do agree with you that it's kind of weird that people write code
without making transactional requirements explicit in the code, but it
seems that the trend is to abstract from that and use the
"Transaction" term as a "Unit of work".
For example I find it strange that - in Java - one has to configure
the isolation levels of transactions to the safest (least efficient)
option possible among the types his *various* use cases require. It's
pretty obvious that it would be more efficient to choose those levels
as "profiles" based on use case, possibly bean or even method level.
I guess that's were complex applications split up in multiple deployments..
What is concerning is that the average developer will write Java code
making assumptions on the underlying transaction guarantees, and will
rarely communicate those as requirements to whoever configures it.
Is that what you aim to solve?
On 6 May 2015 at 10:01, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
When talking to people about OGM, there is always that awkward moment when
you need to explain that TX demarcation is required also for
non-transactional data stores.
While it makes sense for our purposes (we use the "TX cycle" to optimise
the work sent to the backend etc.), I can understand people who find that
odd API-wise. So I was thinking about how this could be improved.
When it comes to CDI, a more "neutral" annotation (and a portable extension
examining it) than @Transactional could be helpful:
@UnitOfWork
public void saveOrderAndCustomer(Order order, Customer customer) {
session.persist( order );
session.persist( customer );
}
By means of the @UnitOfWork annotation it would be expressed that the
entire method should run as one "transaction". This also could be used to
specify an error handler for our new API to be applied for this unit of
work:
@UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
public void saveOrderAndCustomer(Order order, Customer customer) { ... }
In non-managed environments, Java-8-style Lambda expressions could be
leveraged nicely to achieve the same:
session.runUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
};
This should feel much nicer to e.g. users of the MongoDB backend than
invoking session.getTransaction().begin()/commit(). It also plays greatly
together with the error handling stuff:
session.buildUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
} )
.onFailedGridDialectOperation( context -> {
// e.g. log failed op
return ErrorHandlingStrategy.ABORT;
} )
.onRollback( context -> {
// e.g. log applied ops
} )
.run();
Of course something equivalent could be done for Java 7, but it'd probably
look not as concise.
Any thoughts?
Cheers,
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:31 a.m.
2015-05-06 11:13 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
Did you consider that the existing definition of "Transaction
boundaries" can have different levels of isolation and guarantees,
depending on how the underlying components are configured?
I didn't, but that's exactly the point. Talking (API-wise) about
"transactions", "isolation levels" does not really make sense if the
underlying backend is non-transactional by its nature.
We just piggy-back on the transaction cycle from ORM to control flushes,
but this doesn't give you any sort of transactional guarantees if not
natively supported. If you e.g. do an explicit flush() in the middle of a
"transaction", these changes will be visible to other clients, no matter
what kind of isolation level has been configured somewhere.
I do agree with you that it's kind of weird that people write code
without making transactional requirements explicit in the code, but
it
seems that the trend is to abstract from that and use the
"Transaction" term as a "Unit of work".
Where do you see this trend? Surely not e.g. in MongoDB or CouchDB? It's
exactly the usage of the term "transaction" which I find irritating for
these stores and which I thus seek to avoid.
For example I find it strange that - in Java - one has to configure
the isolation levels of transactions to the safest (least efficient)
option possible among the types his *various* use cases require. It's
pretty obvious that it would be more efficient to choose those levels
as "profiles" based on use case, possibly bean or even method level.
I guess that's were complex applications split up in multiple deployments..
What is concerning is that the average developer will write Java code
making assumptions on the underlying transaction guarantees, and will
rarely communicate those as requirements to whoever configures it.
Is that what you aim to solve?
Not really. What I aim to solve is to avoid making the user work with APIs
which
suggest certain kinds of guarantees which in reality are not there
for certain backends.
On 6 May 2015 at 10:01, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> Hi,
>
> When talking to people about OGM, there is always that awkward moment
when
> you need to explain that TX demarcation is required also for
> non-transactional data stores.
>
> While it makes sense for our purposes (we use the "TX cycle" to optimise
> the work sent to the backend etc.), I can understand people who find that
> odd API-wise. So I was thinking about how this could be improved.
>
> When it comes to CDI, a more "neutral" annotation (and a portable
extension
> examining it) than @Transactional could be helpful:
>
> @UnitOfWork
> public void saveOrderAndCustomer(Order order, Customer customer) {
> session.persist( order );
> session.persist( customer );
> }
>
> By means of the @UnitOfWork annotation it would be expressed that the
> entire method should run as one "transaction". This also could be used to
> specify an error handler for our new API to be applied for this unit of
> work:
>
> @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
> public void saveOrderAndCustomer(Order order, Customer customer) {
... }
>
> In non-managed environments, Java-8-style Lambda expressions could be
> leveraged nicely to achieve the same:
>
> session.runUnitOfWork( () -> {
> session.persist( order );
> session.persist( customer );
> };
>
> This should feel much nicer to e.g. users of the MongoDB backend than
> invoking session.getTransaction().begin()/commit(). It also plays greatly
> together with the error handling stuff:
>
> session.buildUnitOfWork( () -> {
> session.persist( order );
> session.persist( customer );
> } )
> .onFailedGridDialectOperation( context -> {
> // e.g. log failed op
> return ErrorHandlingStrategy.ABORT;
> } )
> .onRollback( context -> {
> // e.g. log applied ops
> } )
> .run();
>
> Of course something equivalent could be done for Java 7, but it'd
probably
> look not as concise.
>
> Any thoughts?
>
> Cheers,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:43 a.m.
Making the user work with a Transaction API even though the storage
doesn't implement it "at all" isn't a novelty of OGM. Remember
MySQL's
MyISAM ?
It's supported by Hibernate, and while InnoDB might be on the rise
compared to MyISAM, it's not dead.
The range of transactional capabilities of different engines varies a
lot in many subtle details which are hard to classify under a single
standard API; In my view not supporting any transactional capability
is just a very low form of transaction capabilities :)
I would totally agree with you that this is a concrete and interesting
problem to solve, but I don't think it's something for OGM to do.
Sanne
On 6 May 2015 at 10:31, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2015-05-06 11:13 GMT+02:00 Sanne Grinovero
<sanne(a)hibernate.org>:
>
> Did you consider that the existing definition of "Transaction
> boundaries" can have different levels of isolation and guarantees,
> depending on how the underlying components are configured?
I didn't, but that's exactly the point. Talking (API-wise) about
"transactions", "isolation levels" does not really make sense if the
underlying backend is non-transactional by its nature.
We just piggy-back on the transaction cycle from ORM to control flushes, but
this doesn't give you any sort of transactional guarantees if not natively
supported. If you e.g. do an explicit flush() in the middle of a
"transaction", these changes will be visible to other clients, no matter
what kind of isolation level has been configured somewhere.
> I do agree with you that it's kind of weird that people write code
> without making transactional requirements explicit in the code, but it
> seems that the trend is to abstract from that and use the
> "Transaction" term as a "Unit of work".
Where do you see this trend? Surely not e.g. in MongoDB or CouchDB? It's
exactly the usage of the term "transaction" which I find irritating for
these stores and which I thus seek to avoid.
> For example I find it strange that - in Java - one has to configure
> the isolation levels of transactions to the safest (least efficient)
> option possible among the types his *various* use cases require. It's
> pretty obvious that it would be more efficient to choose those levels
> as "profiles" based on use case, possibly bean or even method level.
> I guess that's were complex applications split up in multiple
> deployments..
>
> What is concerning is that the average developer will write Java code
> making assumptions on the underlying transaction guarantees, and will
> rarely communicate those as requirements to whoever configures it.
> Is that what you aim to solve?
>
Not really. What I aim to solve is to avoid making the user work with APIs
which suggest certain kinds of guarantees which in reality are not there for
certain backends.
>
>
>
>
> On 6 May 2015 at 10:01, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > Hi,
> >
> > When talking to people about OGM, there is always that awkward moment
> > when
> > you need to explain that TX demarcation is required also for
> > non-transactional data stores.
> >
> > While it makes sense for our purposes (we use the "TX cycle" to
optimise
> > the work sent to the backend etc.), I can understand people who find
> > that
> > odd API-wise. So I was thinking about how this could be improved.
> >
> > When it comes to CDI, a more "neutral" annotation (and a portable
> > extension
> > examining it) than @Transactional could be helpful:
> >
> > @UnitOfWork
> > public void saveOrderAndCustomer(Order order, Customer customer) {
> > session.persist( order );
> > session.persist( customer );
> > }
> >
> > By means of the @UnitOfWork annotation it would be expressed that the
> > entire method should run as one "transaction". This also could be
used
> > to
> > specify an error handler for our new API to be applied for this unit of
> > work:
> >
> > @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
> > public void saveOrderAndCustomer(Order order, Customer customer) {
> > ... }
> >
> > In non-managed environments, Java-8-style Lambda expressions could be
> > leveraged nicely to achieve the same:
> >
> > session.runUnitOfWork( () -> {
> > session.persist( order );
> > session.persist( customer );
> > };
> >
> > This should feel much nicer to e.g. users of the MongoDB backend than
> > invoking session.getTransaction().begin()/commit(). It also plays
> > greatly
> > together with the error handling stuff:
> >
> > session.buildUnitOfWork( () -> {
> > session.persist( order );
> > session.persist( customer );
> > } )
> > .onFailedGridDialectOperation( context -> {
> > // e.g. log failed op
> > return ErrorHandlingStrategy.ABORT;
> > } )
> > .onRollback( context -> {
> > // e.g. log applied ops
> > } )
> > .run();
> >
> > Of course something equivalent could be done for Java 7, but it'd
> > probably
> > look not as concise.
> >
> > Any thoughts?
> >
> > Cheers,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:51 a.m.
2015-05-06 11:43 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
Making the user work with a Transaction API even though the storage
doesn't implement it "at all" isn't a novelty of OGM. Remember
MySQL's
MyISAM ?
It's supported by Hibernate, and while InnoDB might be on the rise
compared to MyISAM, it's not dead.
Novelty or not, it just seems not the best approach to me. It's one of the
things leading to those "if all you've got is a hammer, all problems look
like a nail" comments.
The range of transactional capabilities of different engines varies
a
lot in many subtle details which are hard to classify under a single
standard API; In my view not supporting any transactional capability
is just a very low form of transaction capabilities :)
I would totally agree with you that this is a concrete and interesting
problem to solve, but I don't think it's something for OGM to do.
Who else should it do?
It's our task to provide sensible APIs for persisting data in different
backends. Requiring users to span "transactions" where there are none isn't
necessarily sensible in my book :)
Sanne
On 6 May 2015 at 10:31, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> 2015-05-06 11:13 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>>
>> Did you consider that the existing definition of "Transaction
>> boundaries" can have different levels of isolation and guarantees,
>> depending on how the underlying components are configured?
>
>
> I didn't, but that's exactly the point. Talking (API-wise) about
> "transactions", "isolation levels" does not really make sense if
the
> underlying backend is non-transactional by its nature.
>
> We just piggy-back on the transaction cycle from ORM to control flushes,
but
> this doesn't give you any sort of transactional guarantees if not
natively
> supported. If you e.g. do an explicit flush() in the middle of a
> "transaction", these changes will be visible to other clients, no matter
> what kind of isolation level has been configured somewhere.
>
>> I do agree with you that it's kind of weird that people write code
>> without making transactional requirements explicit in the code, but it
>> seems that the trend is to abstract from that and use the
>> "Transaction" term as a "Unit of work".
>
>
> Where do you see this trend? Surely not e.g. in MongoDB or CouchDB? It's
> exactly the usage of the term "transaction" which I find irritating for
> these stores and which I thus seek to avoid.
>
>> For example I find it strange that - in Java - one has to configure
>> the isolation levels of transactions to the safest (least efficient)
>> option possible among the types his *various* use cases require. It's
>> pretty obvious that it would be more efficient to choose those levels
>> as "profiles" based on use case, possibly bean or even method level.
>> I guess that's were complex applications split up in multiple
>> deployments..
>>
>> What is concerning is that the average developer will write Java code
>> making assumptions on the underlying transaction guarantees, and will
>> rarely communicate those as requirements to whoever configures it.
>> Is that what you aim to solve?
>>
> Not really. What I aim to solve is to avoid making the user work with
APIs
> which suggest certain kinds of guarantees which in reality are not there
for
> certain backends.
>>
>>
>>
>>
>> On 6 May 2015 at 10:01, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>> > Hi,
>> >
>> > When talking to people about OGM, there is always that awkward moment
>> > when
>> > you need to explain that TX demarcation is required also for
>> > non-transactional data stores.
>> >
>> > While it makes sense for our purposes (we use the "TX cycle" to
optimise
>> > the work sent to the backend etc.), I can understand people who find
>> > that
>> > odd API-wise. So I was thinking about how this could be improved.
>> >
>> > When it comes to CDI, a more "neutral" annotation (and a
portable
>> > extension
>> > examining it) than @Transactional could be helpful:
>> >
>> > @UnitOfWork
>> > public void saveOrderAndCustomer(Order order, Customer customer) {
>> > session.persist( order );
>> > session.persist( customer );
>> > }
>> >
>> > By means of the @UnitOfWork annotation it would be expressed that the
>> > entire method should run as one "transaction". This also could be
used
>> > to
>> > specify an error handler for our new API to be applied for this unit
of
>> > work:
>> >
>> > @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
>> > public void saveOrderAndCustomer(Order order, Customer customer) {
>> > ... }
>> >
>> > In non-managed environments, Java-8-style Lambda expressions could be
>> > leveraged nicely to achieve the same:
>> >
>> > session.runUnitOfWork( () -> {
>> > session.persist( order );
>> > session.persist( customer );
>> > };
>> >
>> > This should feel much nicer to e.g. users of the MongoDB backend than
>> > invoking session.getTransaction().begin()/commit(). It also plays
>> > greatly
>> > together with the error handling stuff:
>> >
>> > session.buildUnitOfWork( () -> {
>> > session.persist( order );
>> > session.persist( customer );
>> > } )
>> > .onFailedGridDialectOperation( context -> {
>> > // e.g. log failed op
>> > return ErrorHandlingStrategy.ABORT;
>> > } )
>> > .onRollback( context -> {
>> > // e.g. log applied ops
>> > } )
>> > .run();
>> >
>> > Of course something equivalent could be done for Java 7, but it'd
>> > probably
>> > look not as concise.
>> >
>> > Any thoughts?
>> >
>> > Cheers,
>> >
>> > --Gunnar
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
2:19 p.m.
It’s an interesting idea.
Let me give you the reasons why I think the transaction API has merits.
There is already a notion of UnitOfWork that was named Conversation in Seam / CDI. But its
span is potentially longer than the span of the updates window. The closer notion of a
UnitOfWork is an EntityManager or a Session.
By introducing @UnitOfWork, you forgo all the integration between application frameworks
and transactions. Here you offer a solution for CDI but we would need one for Java EE non
CDI and one for Spring and one for Grails and one for… I understand you reluctance to call
a Tiger a Cat but they are commonly referred as Cats.
Back to our problem, you either
- teach people that transaction is not what they might understand of transactions - if
they even know what that means these days ;)
- teach them a new concept that suspiciously looks like a transaction anyways and force
them to do the integration of that “thing” with their universe.
I like the exploration of lamda usage for the Hibernate APIs but we probably should think
about it in the larger scheme of ORM and in this async API trend. What could we do.
Note also that your example reflects a simple example where you *whole* unit of work is
very simple and does not span services / DAOs. If it spans services / DAOs, then the
lambda approach sort of fails a little by as you need to reach the session from within
these nested service calls.
I am relatively open on these proposals but we need to flesh them out much better before
we can consider them seriously (say for the next sprint).
On 06 May 2015, at 11:01, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
Hi,
When talking to people about OGM, there is always that awkward moment when
you need to explain that TX demarcation is required also for
non-transactional data stores.
While it makes sense for our purposes (we use the "TX cycle" to optimise
the work sent to the backend etc.), I can understand people who find that
odd API-wise. So I was thinking about how this could be improved.
When it comes to CDI, a more "neutral" annotation (and a portable extension
examining it) than @Transactional could be helpful:
@UnitOfWork
public void saveOrderAndCustomer(Order order, Customer customer) {
session.persist( order );
session.persist( customer );
}
By means of the @UnitOfWork annotation it would be expressed that the
entire method should run as one "transaction". This also could be used to
specify an error handler for our new API to be applied for this unit of
work:
@UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
public void saveOrderAndCustomer(Order order, Customer customer) { ... }
In non-managed environments, Java-8-style Lambda expressions could be
leveraged nicely to achieve the same:
session.runUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
};
This should feel much nicer to e.g. users of the MongoDB backend than
invoking session.getTransaction().begin()/commit(). It also plays greatly
together with the error handling stuff:
session.buildUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
} )
.onFailedGridDialectOperation( context -> {
// e.g. log failed op
return ErrorHandlingStrategy.ABORT;
} )
.onRollback( context -> {
// e.g. log applied ops
} )
.run();
Of course something equivalent could be done for Java 7, but it'd probably
look not as concise.
Any thoughts?
Cheers,
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:16 p.m.
2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
It’s an interesting idea.
Let me give you the reasons why I think the transaction API has merits.
There is already a notion of UnitOfWork that was named Conversation in
Seam / CDI. But its span is potentially longer than the span of the updates
window. The closer notion of a UnitOfWork is an EntityManager or a Session.
By introducing @UnitOfWork, you forgo all the integration between
application frameworks and transactions. Here you offer a solution
for CDI
but we would need one for Java EE non CDI and one for Spring and one for
Grails and one for…
The current integrations would continue to work. So e.g. EJB non-CDI would
still use JTA as is today. I don't find it to be a big problem there, as
it's much more under the covers (which is why it's nice to show EJBs in
demos ;). Same for the others basically.
I understand you reluctance to call a Tiger a Cat but they are commonly
referred as Cats.
Back to our problem, you either
- teach people that transaction is not what they might understand of
transactions - if they even know what that means these days ;)
- teach them a new concept that suspiciously looks like a transaction
anyways and force them to do the integration of that “thing” with their
universe.
I'd prefer the latter. The good thing is that it is up to us to
describe/document what the "thing" is, so we can manage expectations
towards it, far better then when using the term "transaction" which
automatically raises certain expectations (smart people will wonder how we
make it work, others may even fall into the trap and believe it is actually
TX).
I like the exploration of lamda usage for the Hibernate APIs but we
probably should think about it in the larger scheme of ORM and in this
async API trend. What could we do.
Note also that your example reflects a simple example where you *whole*
unit of work is very simple and does not span services / DAOs. If it spans
services / DAOs, then the lambda approach sort of fails a little by as you
need to reach the session from within these nested service calls.
Yes, that is a good point. Probably we'd also need something like
beginUnitOfWork(). Maybe something like this is the better approach:
session.buildUnitOfWork()
.onFailedGridDialectOperation( context -> {
// e.g. log failed op
return ErrorHandlingStrategy.ABORT;
} )
.onRollback( context -> {
// e.g. log applied ops
} )
.begin();
session.persist( order );
session.persist( customer );
session.finishUnitOfWork();
I am relatively open on these proposals but we need to flesh them out
much
better before we can consider them seriously (say for the next sprint).
Sure, it's not fully worked out, I just wanted to quickly gauge general
interest in this. I will file an issue.
> On 06 May 2015, at 11:01, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> Hi,
>
> When talking to people about OGM, there is always that awkward moment
when
> you need to explain that TX demarcation is required also for
> non-transactional data stores.
>
> While it makes sense for our purposes (we use the "TX cycle" to optimise
> the work sent to the backend etc.), I can understand people who find that
> odd API-wise. So I was thinking about how this could be improved.
>
> When it comes to CDI, a more "neutral" annotation (and a portable
extension
> examining it) than @Transactional could be helpful:
>
> @UnitOfWork
> public void saveOrderAndCustomer(Order order, Customer customer) {
> session.persist( order );
> session.persist( customer );
> }
>
> By means of the @UnitOfWork annotation it would be expressed that the
> entire method should run as one "transaction". This also could be used to
> specify an error handler for our new API to be applied for this unit of
> work:
>
> @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
> public void saveOrderAndCustomer(Order order, Customer customer) {
... }
>
> In non-managed environments, Java-8-style Lambda expressions could be
> leveraged nicely to achieve the same:
>
> session.runUnitOfWork( () -> {
> session.persist( order );
> session.persist( customer );
> };
>
> This should feel much nicer to e.g. users of the MongoDB backend than
> invoking session.getTransaction().begin()/commit(). It also plays greatly
> together with the error handling stuff:
>
> session.buildUnitOfWork( () -> {
> session.persist( order );
> session.persist( customer );
> } )
> .onFailedGridDialectOperation( context -> {
> // e.g. log failed op
> return ErrorHandlingStrategy.ABORT;
> } )
> .onRollback( context -> {
> // e.g. log applied ops
> } )
> .run();
>
> Of course something equivalent could be done for Java 7, but it'd
probably
> look not as concise.
>
> Any thoughts?
>
> Cheers,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:58 p.m.
Hi,
On Wed, May 06, 2015 at 11:01:29AM +0200, Gunnar Morling wrote:
When talking to people about OGM, there is always that awkward moment
when
you need to explain that TX demarcation is required also for
non-transactional data stores.
While it makes sense for our purposes (we use the "TX cycle" to optimise
the work sent to the backend etc.), I can understand people who find that
odd API-wise. So I was thinking about how this could be improved.
Personally I count myself to the category of people who raise an eyebrow about
using transactions for non transactional data stores.
When it comes to CDI, a more "neutral" annotation (and a
portable extension
examining it) than @Transactional could be helpful:
@UnitOfWork
public void saveOrderAndCustomer(Order order, Customer customer) {
session.persist( order );
session.persist( customer );
}
By means of the @UnitOfWork annotation it would be expressed that the
entire method should run as one "transaction". This also could be used to
specify an error handler for our new API to be applied for this unit of
work:
@UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
public void saveOrderAndCustomer(Order order, Customer customer) { ... }
Interesting.
In non-managed environments, Java-8-style Lambda expressions could
be
leveraged nicely to achieve the same:
session.runUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
};
This should feel much nicer to e.g. users of the MongoDB backend than
invoking session.getTransaction().begin()/commit(). It also plays greatly
together with the error handling stuff:
session.buildUnitOfWork( () -> {
session.persist( order );
session.persist( customer );
} )
.onFailedGridDialectOperation( context -> {
// e.g. log failed op
return ErrorHandlingStrategy.ABORT;
} )
.onRollback( context -> {
// e.g. log applied ops
} )
.run();
Of course something equivalent could be done for Java 7, but it'd probably
look not as concise.
I like how the lambdas play out there. Personally I think it would be more important
to start with a Java 7 based approach. Only offering this type of functionality for Java
8
might limit the potential user base and it also adds some complexity to OGM as well,
since you probably still want to offer Java 7 compatible artifacts. That said, I think
the
lambda approach has definitely a future.
--Hardy
10 p.m.
Hi,
On Wed, May 06, 2015 at 10:13:38AM +0100, Sanne Grinovero wrote:
I do agree with you that it's kind of weird that people write
code
without making transactional requirements explicit in the code, but it
seems that the trend is to abstract from that and use the
"Transaction" term as a "Unit of work".
What are you referring to? Where do you see this trend.
For example I find it strange that - in Java - one has to configure
the isolation levels of transactions to the safest (least efficient)
option possible among the types his *various* use cases require. It's
pretty obvious that it would be more efficient to choose those levels
as "profiles" based on use case, possibly bean or even method level.
I guess that's were complex applications split up in multiple deployments..
I am not sure I am quite following you on this.
--Hardy
10:10 p.m.
Hi,
On Wed, May 06, 2015 at 03:16:16PM +0200, Gunnar Morling wrote:
By introducing @UnitOfWork, you forgo all the integration between
> application frameworks and transactions. Here you offer a solution for CDI
> but we would need one for Java EE non CDI and one for Spring and one for
> Grails and one for…
The current integrations would continue to work. So e.g. EJB non-CDI would
still use JTA as is today. I don't find it to be a big problem there, as
it's much more under the covers (which is why it's nice to show EJBs in
demos ;). Same for the others basically.
+1
I understand you reluctance to call a Tiger a Cat but they are
commonly
> referred as Cats.
> Back to our problem, you either
> - teach people that transaction is not what they might understand of
> transactions - if they even know what that means these days ;)
> - teach them a new concept that suspiciously looks like a transaction
> anyways and force them to do the integration of that “thing” with their
> universe.
>
I'd prefer the latter. The good thing is that it is up to us to
describe/document what the "thing" is, so we can manage expectations
towards it, far better then when using the term "transaction" which
automatically raises certain expectations (smart people will wonder how we
make it work, others may even fall into the trap and believe it is actually
TX).
A clear +1 for the latter options from me as well. It's all about managing
expectations
and right now we conjure the wrong ones for non transactional databases.
This transaction issue is imo one of the big sore points of OGM. The other one
is, that there is no clear separation on what one can and cannot do using JPA.
Some things will never be supported others could work, but are not implemented yet.
One never really knows. It has a bit of a sour after taste.
--Hardy
8:12 a.m.
On 06 May 2015, at 15:16, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org
<mailto:emmanuel@hibernate.org>>:
It’s an interesting idea.
Let me give you the reasons why I think the transaction API has merits.
There is already a notion of UnitOfWork that was named Conversation in Seam / CDI. But
its span is potentially longer than the span of the updates window. The closer notion of a
UnitOfWork is an EntityManager or a Session.
By introducing @UnitOfWork, you forgo all the integration between application frameworks
and transactions. Here you offer a solution for CDI but we would need one for Java EE non
CDI and one for Spring and one for Grails and one for…
The current integrations would continue to work. So e.g. EJB non-CDI would still use JTA
as is today. I don't find it to be a big problem there, as it's much more under
the covers (which is why it's nice to show EJBs in demos ;). Same for the others
basically.
OK so you would still support essentially Hibernate Transactions with how we wired them
with (compensation). But also add this new concept that would do exactly the same thing
for people offended by the term transaction? Or am I misunderstanding something.
8:38 a.m.
2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 06 May 2015, at 15:16, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> It’s an interesting idea.
> Let me give you the reasons why I think the transaction API has merits.
>
> There is already a notion of UnitOfWork that was named Conversation in
> Seam / CDI. But its span is potentially longer than the span of the updates
> window. The closer notion of a UnitOfWork is an EntityManager or a Session.
By introducing @UnitOfWork, you forgo all the integration between
> application frameworks and transactions. Here you offer a solution for CDI
> but we would need one for Java EE non CDI and one for Spring and one for
> Grails and one for…
The current integrations would continue to work. So e.g. EJB non-CDI would
still use JTA as is today. I don't find it to be a big problem there, as
it's much more under the covers (which is why it's nice to show EJBs in
demos ;). Same for the others basically.
OK so you would still support essentially Hibernate Transactions with how
we wired them with (compensation).
Yes, right. Under the hood essentially nothing would change.
But also add this new concept that would do exactly the same thing
for
people offended by the term transaction? Or am I misunderstanding something.
It would be similar, but not the same. Specifically, such API would not
promise rollback capabilities or isolation from other, concurrent units of
work when e.g. doing explicit flushes.
10:29 a.m.
On 07 May 2015, at 08:38, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org
<mailto:emmanuel@hibernate.org>>:
> On 06 May 2015, at 15:16, Gunnar Morling <gunnar(a)hibernate.org
<mailto:gunnar@hibernate.org>> wrote:
>
>
>
> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org
<mailto:emmanuel@hibernate.org>>:
> It’s an interesting idea.
> Let me give you the reasons why I think the transaction API has merits.
>
> There is already a notion of UnitOfWork that was named Conversation in Seam / CDI.
But its span is potentially longer than the span of the updates window. The closer notion
of a UnitOfWork is an EntityManager or a Session.
> By introducing @UnitOfWork, you forgo all the integration between application
frameworks and transactions. Here you offer a solution for CDI but we would need one for
Java EE non CDI and one for Spring and one for Grails and one for…
>
> The current integrations would continue to work. So e.g. EJB non-CDI would still use
JTA as is today. I don't find it to be a big problem there, as it's much more
under the covers (which is why it's nice to show EJBs in demos ;). Same for the others
basically.
OK so you would still support essentially Hibernate Transactions with how we wired them
with (compensation).
Yes, right. Under the hood essentially nothing would change.
But also add this new concept that would do exactly the same thing for people offended by
the term transaction? Or am I misunderstanding something.
It would be similar, but not the same. Specifically, such API would not promise rollback
capabilities or isolation from other, concurrent units of work when e.g. doing explicit
flushes.
But I could still use session.getTransaction() and get the “wrong” behavior?
5:51 p.m.
2015-05-07 10:29 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 07 May 2015, at 08:38, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 06 May 2015, at 15:16, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
>
>
> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
>> It’s an interesting idea.
>> Let me give you the reasons why I think the transaction API has merits.
>>
>> There is already a notion of UnitOfWork that was named Conversation in
>> Seam / CDI. But its span is potentially longer than the span of the updates
>> window. The closer notion of a UnitOfWork is an EntityManager or a Session.
>
> By introducing @UnitOfWork, you forgo all the integration between
>> application frameworks and transactions. Here you offer a solution for CDI
>> but we would need one for Java EE non CDI and one for Spring and one for
>> Grails and one for…
>
>
> The current integrations would continue to work. So e.g. EJB non-CDI
> would still use JTA as is today. I don't find it to be a big problem there,
> as it's much more under the covers (which is why it's nice to show EJBs in
> demos ;). Same for the others basically.
>
>
> OK so you would still support essentially Hibernate Transactions with how
> we wired them with (compensation).
>
Yes, right. Under the hood essentially nothing would change.
> But also add this new concept that would do exactly the same thing for
> people offended by the term transaction? Or am I misunderstanding something.
>
It would be similar, but not the same. Specifically, such API would not
promise rollback capabilities or isolation from other, concurrent units of
work when e.g. doing explicit flushes.
But I could still use session.getTransaction() and get the “wrong”
behavior?
I think it's the general question should we have an API which offers
"everything", i.e. the sum of all functionality of all backends, meaning
that some parts of the announced API functionality will fail at runtime
(either silently or with an exception) on some backends. Or should we have
a more limited API which is supported everywhere, and then allow to
"unwrap" for certain backends (or families) and access advanced
functionality just applying to those (as we e.g. do with the configuration
API).
Currently OgmSession is the former, i.e. you could invoke getTransaction()
and basically achieve the same as with the proposed alternative. But you
could also try to rollback() and then it would fail, depending on the store.
I feel like the latter a bit better. For that we'd need a more limited
OgmSession contract, not extending ORM's Session. This could e.g. host the
runWorkUnit() functionality which is portable across backends.
Then there could be something like
OgmSession.as(TransactionalSession.class).beginTransaction(). Here you
would explicitly opt into transactional functionality. Of course you still
could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in
a better way and help to manage people's expectations towards supported
functionality. Or, e.g. with CDI it could even fail right at deploy of no
TransactionalSession bean can be produced as per the current backend.
9:11 a.m.
On Thu 2015-05-07 17:51, Gunnar Morling wrote:
> But I could still use session.getTransaction() and get the
“wrong”
> behavior?
>
I think it's the general question should we have an API which offers
"everything", i.e. the sum of all functionality of all backends, meaning
that some parts of the announced API functionality will fail at runtime
(either silently or with an exception) on some backends. Or should we have
a more limited API which is supported everywhere, and then allow to
"unwrap" for certain backends (or families) and access advanced
functionality just applying to those (as we e.g. do with the configuration
API).
Currently OgmSession is the former, i.e. you could invoke getTransaction()
and basically achieve the same as with the proposed alternative. But you
could also try to rollback() and then it would fail, depending on the store.
I feel like the latter a bit better. For that we'd need a more limited
OgmSession contract, not extending ORM's Session. This could e.g. host the
runWorkUnit() functionality which is portable across backends.
Then there could be something like
OgmSession.as(TransactionalSession.class).beginTransaction(). Here you
would explicitly opt into transactional functionality. Of course you still
could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in
a better way and help to manage people's expectations towards supported
functionality. Or, e.g. with CDI it could even fail right at deploy of no
TransactionalSession bean can be produced as per the current backend.
I am not sure how you reconcile that with the idea that OGM is a JPA
persistence provider implementation that integrates with things like app
servers and that these guys do use the `EntityManager` API. Will you forbid
app servers to expose rollback on the JTA APIs? And to inject a
`EntityManager` and force an `OgmEntityManager`?
3262
days inactive
3271
days old
14 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Sanne Grinovero