castor
  1. castor
  2. CASTOR-2713 Refactoring SQLStatementStore
  3. CASTOR-2716

Separates the PrepareStatement functionality from executeStatement.

    Details

    • Type: Sub-task Sub-task
    • Status: Closed Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.3.1
    • Component/s: JDO queries
    • Labels:
      None
    • Number of attachments :
      2
    1. patch-c2716-20090518.txt
      23 kB
      AHMAD HASSAN
    2. patch-C2716-20090519.txt
      24 kB
      Ralf Joachim

      Activity

      Hide
      Werner Guttmann added a comment -

      No problem. I am just trying to follow as much as I can. Quite honestly, I'd opt for option c) in this context, especially when taking prepared statement pooling into consideration. But let's have this discussion once we have to have it.

      Which kind of makes me ask the next question: I was thinking about shipping an 1.3.1 release within the next few weeks, as I think we should try to make the regression changes available. How does this impact your work here ?

      Show
      Werner Guttmann added a comment - No problem. I am just trying to follow as much as I can. Quite honestly, I'd opt for option c) in this context, especially when taking prepared statement pooling into consideration. But let's have this discussion once we have to have it. Which kind of makes me ask the next question: I was thinking about shipping an 1.3.1 release within the next few weeks, as I think we should try to make the regression changes available. How does this impact your work here ?
      Hide
      Ralf Joachim added a comment -

      I also prefer method attributes but I first have to look at the impacts on design where I have not taken concurrency into account earlier.

      I also think shipping a 1.3.1 release soon would be a good idea. I think within a few weeks we are able to finish the reorganization of delete and update statements. Thereafter we try to take even more care not to introduce new issues.

      Show
      Ralf Joachim added a comment - I also prefer method attributes but I first have to look at the impacts on design where I have not taken concurrency into account earlier. I also think shipping a 1.3.1 release soon would be a good idea. I think within a few weeks we are able to finish the reorganization of delete and update statements. Thereafter we try to take even more care not to introduce new issues.
      Hide
      Werner Guttmann added a comment -

      Re: 1.3.1: great. I am facing a launch currently, so it won't be before next week that I will be able to return my attention to Castor.

      Show
      Werner Guttmann added a comment - Re: 1.3.1: great. I am facing a launch currently, so it won't be before next week that I will be able to return my attention to Castor.
      Hide
      Werner Guttmann added a comment -

      Can I ask you a small question: who's using classes like SqlStatementStore et alis at run-time. I guess there will be instances of each of those per Java class that has a JDO mapping. Correct ? If that's the case, I do not think that we want to synchronize at all. There's absolutely no reason as to why deleting an instance of class A should have any relation to deleting an instance of class B. And the same applies to two instances of class A. At any time, all these operations should be possible in parallel.

      Show
      Werner Guttmann added a comment - Can I ask you a small question: who's using classes like SqlStatementStore et alis at run-time. I guess there will be instances of each of those per Java class that has a JDO mapping. Correct ? If that's the case, I do not think that we want to synchronize at all. There's absolutely no reason as to why deleting an instance of class A should have any relation to deleting an instance of class B . And the same applies to two instances of class A . At any time, all these operations should be possible in parallel.
      Hide
      Ralf Joachim added a comment -

      You are right, there is one SQLStatementStore instance for each Java class in JDO mapping.

      Problem happens if 2 threads update instances of class A at the same time. This is the only case where we see concurrency problems when prepared statement is a class variable. It is also the only case where the synchronization takes effect at the moment. Concurrent changes to entities of different classes are not affected.

      Show
      Ralf Joachim added a comment - You are right, there is one SQLStatementStore instance for each Java class in JDO mapping. Problem happens if 2 threads update instances of class A at the same time. This is the only case where we see concurrency problems when prepared statement is a class variable. It is also the only case where the synchronization takes effect at the moment. Concurrent changes to entities of different classes are not affected.

        People

        • Assignee:
          AHMAD HASSAN
          Reporter:
          AHMAD HASSAN
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: