Announcement Announcement Module
Collapse
No announcement yet.
Applying transaction boundaries Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Oh, thanks a lot Daniel, I did it his way n the demos and samples but didn't realize that it had this impact, could you raise an JIRA issue so that we make sure we add this note to the documentation?

    Michael, any luck breaking your GH project ?

    Comment


    • #17
      Thanks for reminding me, just been able to break it now! Try running the refer test in https://github.com/mikeycmccarthy/Sp...eImplTest.java.

      Note that I'm not putting any transactional annotations in this test - I'm testing the service and we keep our transaction boundaries there so I want to test that. If you flip the tx type in the test context from aspectj to proxy it works. I don't understand enough about the differences to know what is going on there so I need to read up on that.

      Comment


      • #18
        Michael,

        if you use <tx:annotation-driven mode="aspectj"/> then AJ takes over handling the @Transactional annotations in your code.
        You must configure aspectj in your pom to do the class file weaving.

        Like so then it works.

        Code:
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>aspectj-maven-plugin</artifactId>
                        <version>1.2</version>
                        <dependencies>
                            <dependency>
                                <groupId>org.aspectj</groupId>
                                <artifactId>aspectjrt</artifactId>
                                <version>1.6.12</version>
                            </dependency>
                            <dependency>
                                <groupId>org.aspectj</groupId>
                                <artifactId>aspectjtools</artifactId>
                                <version>1.6.12</version>
                            </dependency>
                        </dependencies>
                        <executions>
                            <execution>
                                <goals>
                                    <goal>compile</goal>
                                    <goal>test-compile</goal>
                                </goals>
                            </execution>
                        </executions>
                        <configuration>
                            <outxml>true</outxml>
                            <aspectLibraries>
                                <aspectLibrary>
                                    <groupId>org.springframework</groupId>
                                    <artifactId>spring-aspects</artifactId>
                                </aspectLibrary>
                            </aspectLibraries>
                            <source>1.6</source>
                            <target>1.6</target>
                        </configuration>
                    </plugin>
        You could also configure load-time weaving for your spring context and your app:

        Code:
        <context:load-time-weaver aspectj-weaving="autodetect"/>
        start the JVM with -javaagent:org.springframework.instrument.jar
        As your test dirties the database it is sensible to add this to your test-class. Otherwise you have to cleanup the db in the @Before method yourself, so the ctx is re-instantiated for every run.
        Code:
        @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)

        I also attach the file with the diff to your repo.
        Attachment
        Attached Files

        Comment


        • #19
          Thanks Michael. Makes sense - context is dirtied everytime you are running tests that don't use the spring testing rollback stuff.
          I've applied to the project and uploaded, strangely the test still fails though. Was there another commit you meant to make?

          Thanks!

          Comment


          • #20
            Michael,

            did you apply the changes in all files ?

            How does the test fail?

            Michael

            Comment


            • #21
              JIRA issue created: https://jira.springsource.org/browse/DATAGRAPH-188

              Regards,
              Daniel
              Last edited by danielgig; Feb 3rd, 2012, 08:48 AM. Reason: wrong link

              Comment


              • #22
                Not adding much to this thread. But Daniel, I highly recommend overriding equals and hashCode in domain objects. Because the default implementation is via ==, which is memory address. So theoretically you could have two domain objects that data wise are the same domain objects, but are two different objects in the heap, and therefore equals will return false.

                While this isn't JPA or Hibernate here, it was required to override equals and hashCode because the apis underneath the querying would use it to make sure it never created two different instances with the same data from the db.

                Especially since these methods are used extensively in Collections, which with data models like we have will have plenty Collections to work with.

                Hope that helps

                Mark

                Comment


                • #23
                  Mark, Daniel,

                  if you want to add anything to the docs, please just fork the project edit the xml in the src/docbk directory and issue a pull request. Thanks a lot.

                  Michael

                  Comment


                  • #24
                    Unfortunatly, I'm having this issue. I have these seperations made (of the MVC controllers), I have the correct entry for <tx:annotation-driven mode="proxy" />, and have tried the others in this thread. But in my service, I get this exception. No issues with my tests, just actual code. It's just not getting wrapped in a transaction.
                    Last edited by treaves; Nov 30th, 2012, 10:30 AM.

                    Comment


                    • #25
                      But your service is injected into your controllers?

                      Comment


                      • #26
                        Yes, they are.

                        Comment


                        • #27
                          Any chance to share the project / a sample project to look at?

                          If you get your service injected elsewhere or pull it directly from the context (e.g. in a single Main class), does the transaction work then?

                          Comment


                          • #28
                            The transactions only work if they are in the classes the services call, which is how I've been working around this. So both the service injection & transaction injection work, just not in the same classes.

                            I'll see about creating a sample project to show this; I have one I've used to demonstrate several other defects in the NEO4j code, so maybe it can be easily modified.

                            Comment

                            Working...
                            X