On Tuesday, June 25, 2019 at 7:23:07 PM UTC+2, Viraj Jasani wrote:
>
> Although this thread is old, I just happened to come across while trying
> to understands internals of guice @Transactional.
>
> If class A has caller method that calls a public @Transactional method in
> it's own class, does Transactional really apply?
> If class A has dependency injected of class B(Singleton), and if class A
> calls a public @Transactional method of class B, I believe Transaction is
> definitely applied. However, it seems that for above scenario(calling
> method of it's own class), I believe Transaction should not be applied.
> Could you please let me know if I am correct?
>
Transactional uses Guice AOP: a subclass will be generated dynamically that
overrides the annotated methods with something like:
@Override
public void foo() {
try {
// …begin transaction…
super.foo();
} catch (Exception e) {
if (shouldRollback(e)) { // depends on @Transactional(rollbackOn=)
// …rollback…
} else {
// …commit…
}
throw e;
}
// …commit…
}
Because this is a subclass, calling @Transactional methods from the same
class will use a transaction. We use this to our advantage in our code
using a package-private @Transactional method:
class UseCase {
public Result execute() {
// preconditions
try {
doInTransaction();
return Result.SUCCESS;
} catch (NoDataFoundException e) {
// …log…
return Result.NOT_FOUND;
} catch (Exception e) {
// …log…
return Result.ERROR
}
}
@Transactional
void doInTransaction() {
// …
}
}
though generally-speaking I avoid Guice Persist in new projects; if only
because there's no validation that @Transactional is correctly applied and
will have any effect (and we've had bugs because of that: @Transaction on
private methods for example, or sometimes in classes that weren't
instantiated by Guice).
> On Saturday, 7 December 2013 01:07:51 UTC+5:30, Armin Bahramshahry wrote:
>>
>> Thanks Stephan!
>>
>> On Thursday, December 5, 2013 12:56:35 PM UTC-8, scl wrote:
>>>
>>> So far I always bound the persistence in a ServletModule (don't knwo
>>> why, just never did it any other way).
>>> But having read the entire persistence code at least twice I cannot
>>> remember anything about request scope.
>>> The only piece of code related to the servlet extension is the
>>> PersistFilter which allows to have a unit of work span a request.
>>> The transactional annotation should be independent of the unit of work
>>> (it starts its own if non is running at the time the annotated method is
>>> executed).
>>>
>>> Also the unit tests in the persist extension are bound in abstract
>>> modules and not in servlet modules.
>>> So I don't think what you are seeing is expected behavior.
>>>
>>> What you could do is set a break point within the annotated method and
>>> check if the JpaLocalTxnInterceptor class is in the call stack.
>>> If this is not the case then the aop interceptor has not picket up the
>>> annotation. Another breakpoint in the constructor would allow you to find
>>> out who is instantiating the object.
>>>
>>> Good luck in finding the root of this issue
>>> Stephan
>>>
>>>
>>> On 12/05/2013 05:36 PM, Armin Bahramshahry wrote:
>>>
>>> So is this behavior not expected?
>>>
>>> On Monday, November 25, 2013 9:34:51 AM UTC-8, Paul Bryan wrote:
>>>>
>>>> Is moving its binding to the ServletModule implicitly changing the
>>>> binding's scope to request?
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/google-guice.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/bb0c267e-d431-4d37-9dfa-566a6deb229d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
