Page 4 of 4 FirstFirst ... 234
Results 31 to 39 of 39

Thread: No transaction in transactional service called from @PostConstruct

  1. #31
    Join Date
    Aug 2008
    Posts
    22

    Default

    Has this or somethings similar become part of the framework already? I also have the problem that no Hibernate session is available in a @PostConstruct

  2. #32
    Join Date
    Nov 2009
    Posts
    24

    Default

    no but the patch works fine!

  3. #33
    Join Date
    Nov 2010
    Posts
    1

    Default

    Thanks for the patch!
    I however have a problem when using it:
    I have an init() method on a DAOImpl, annotated as @PostInitialize. This method is not part of the interface.

    When the method or class is also annotated as @Transactional, a proxy is created for the DAOImpl class. However the scan does not pick up the PostInitialize on this proxy as the method is not even part of the proxy method list. Adding the method to the interface didn't solve the problem either. Although it was now present, the PostInitialize annotation was not picked up. Moving the annotation to the interface doesn't help either. Does the fact that annotations are not inherited got something to do with this?

    A hibernate session is required for the init() to work, thats the whole point of the PostInitializer. Should PostInitialize perhaps provide a Transaction scope to run the init() methods in?

    I'm not convinced that a method like init() should always be part of the interface. I would like to leave it up to the implementer to decide if his DAO needs cache warmup.

    I'm using spring 3.0.4.
    Last edited by fiaskow; Nov 2nd, 2010 at 02:37 AM.

  4. #34

    Default

    fiaskow, not sure it can be done. You see, all we do is plain old Java reflection. We got an object and check for its methods (in all morphs). If the object itself is Spring proxy, created by usual Spring AOP (JDK dynamic proxy) it will contain only the methods of the interface.

  5. #35
    Join Date
    Nov 2010
    Posts
    5

    Default

    would like to leave it up to the implementer to decide if his DAO needs cache warmup.

  6. #36
    Join Date
    Apr 2011
    Posts
    1

    Default I have done it different way finaly

    Hi folks.

    I have experimented with @PostInitialize and finally I have decided to use TransactionalTemplate. It works well without problems for us.

    I described it here - http://javatweet.blogspot.com/2011/0...sses-post.html

  7. #37
    Join Date
    Nov 2011
    Posts
    12

    Default

    Quote Originally Posted by Petr Skokan View Post
    Hi folks.

    I have experimented with @PostInitialize and finally I have decided to use TransactionalTemplate. It works well without problems for us.

    I described it here - http://javatweet.blogspot.com/2011/0...sses-post.html
    You could have put the @Transactional on the onApplicationEvent() and call directly to the DAO instead of using the TransactionalTemplate...

  8. #38
    Join Date
    Dec 2012
    Posts
    3

    Default

    cool,
    just for ease of use (one download rather than two), I'm re-posting the complete patched version, with the exclusion of a debug print that mistakenly infiltrated the code previously.
    Hefei Kimay Electrical Appliance Co,Ltd

    Commercial Refrigerators

  9. #39
    Join Date
    Nov 2011
    Posts
    12

    Default Working good, but...

    Quote Originally Posted by zvizvi View Post
    good of you!
    Thanks for the patch. It's working fine, with @Transactional and @PostInitialize.
    However, I did found one issue with it.
    When the Bean using the @PostInitialize have an interface, the runner does not work, as it tries to iterate the Proxy methods instread of the class mathods.

    I'm using spring 3.1.
    Anyone know of a newly added feature in spring 3.1 that can work around this issue, w/o PostInitialize?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •