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 does
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 yo
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 you try to run your test
Andreas Fredriksson wrote:
> 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 r
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 vi
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 synchroniz
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 synchronizat
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 you try to run your test using
> the latest development sour
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 pro
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 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.
>
>
> May
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 befor
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 t
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.
Replying to myself here because I got curious of wheter a testcase would
reproduce the problem, so I wrote one.
This self-contained test class produces the deadlock in a matter of
seconds on my 2-CPU workstation box; you might need to tweak it a bit to
get the bug on other machines. Sending -QUIT
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 (u
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 fi
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 ot
18 matches
Mail list logo
