On Tue, 2005-09-20 at 10:20 -0700, Daniel John Debrunner wrote:
The changes Knut pointed out have been merged to 10.1. If you can build
the 10.1 branch and try them out that would be great, otherwise you
could wait for a snapshot and try that out.
Daniel,
the version on the 10.1 branch
Daniel John Debrunner wrote:
Andreas Fredriksson wrote:
On Thu, 2005-09-15 at 09:59 +0200, Knut Anders Hatlen wrote:
Your patch is against Derby 10.1.1.0, but I see that the development
sources have changed since that version. Some of the changes are
similar to those you proposed. Could
On Wed, 2005-09-14 at 09:18 -0700, Daniel John Debrunner wrote:
Andreas Fredriksson wrote:
Thanks for the patch, it may provide the correct approach but from a
quick look the patch has some incorrect synchronization.
For example, this extract.
+ synchronized (this) {
+
Andreas Fredriksson [EMAIL PROTECTED] writes:
On Wed, 2005-09-14 at 08:51 +0200, Andreas Fredriksson wrote:
I think the only fix is to rewrite the class definition code in Derby to
avoid taking a lock on the helper objects, but I don't know the source
code well enough to write a proper fix.
Andreas Fredriksson wrote:
On Wed, 2005-09-14 at 09:18 -0700, Daniel John Debrunner wrote:
As another general example, if I ever see code like this I know the
coder maybe unclear on synchronization.
public synchronized int getCount()
{
return count;
}
The synchronization here doesn't
On Thu, 2005-09-15 at 07:39 -0700, Daniel John Debrunner wrote:
I'm more talking from a functional level. Even with the synchronization
the caller of the method is just seeing a value from the past, no
guarantees over it being the latest once the method returns. As soon
as the synchronization
On Thursday 15 September 2005 09:52, Andreas Fredriksson wrote:
[SNIP]
The point I was trying to make is that if there are no locks involved at
all, and only a single write of a field (as appears to be the case
here), a reader might theoretically never see the written value, ever,
as the view
On Tue, 2005-09-13 at 09:23 -0700, Daniel John Debrunner wrote:
Replying to myself here because I got curious of wheter a testcase would
reproduce the problem, so I wrote one.
Wow, very cool!
Maybe next step would be you fixing the bug! ;-)
It's amazing how much fun it can be to
On Wed, 2005-09-14 at 08:51 +0200, Andreas Fredriksson wrote:
I think the only fix is to rewrite the class definition code in Derby to
avoid taking a lock on the helper objects, but I don't know the source
code well enough to write a proper fix.
Maybe I should spend more time tweaking before
Andreas Fredriksson wrote:
On Wed, 2005-09-14 at 08:51 +0200, Andreas Fredriksson wrote:
I think the only fix is to rewrite the class definition code in Derby to
avoid taking a lock on the helper objects, but I don't know the source
code well enough to write a proper fix.
Maybe I should
Hey list,
we've re-targeted our system to Derby and now we're seeing some class
loading-related deadlocks.
To give some background, our system loads code from the database and
other various sources (through our own set of class loaders). This has
worked fine with Oracle, MS SQL Server and many
Andreas Fredriksson wrote:
Hey list,
we've re-targeted our system to Derby and now we're seeing some class
loading-related deadlocks.
To give some background, our system loads code from the database and
other various sources (through our own set of class loaders). This has
worked fine
On Tue, 2005-09-13 at 06:52 -0700, Daniel John Debrunner wrote:
I working in Derby's classloader area at the moment, so I'll look into
this, do you have a simple reproducible case?
Hi Daniel,
I don't think it's easily reproducible without breaking some rules.
Here's an idea for a testcase
Andreas Fredriksson wrote:
Replying to myself here because I got curious of wheter a testcase would
reproduce the problem, so I wrote one.
Wow, very cool!
Maybe next step would be you fixing the bug! ;-)
Thanks,
Dan.
14 matches
Mail list logo
