When I was doing the classloader work, I had to grant permission to the
Derby codebase to be able to do classloader-related work
(createClassloader, accessClassInPackage.sun.reflect, getClassloader,
getProtectionDomain).
How do I know whether granting a certain permission is shadowing a "bug"
Øystein Grøvlen wrote:
>>"DJD(" == Daniel John Debrunner (JIRA) writes:
>
>
> DJD(> This patch added two new tests, RecoveryAfterBackup and
> DJD(> RecoveryAfterBackupSetup, both of which are being run
> DJD(> without a SecurityManager due to the noSecurityManager=true
> DJD
> "DJD(" == Daniel John Debrunner (JIRA) writes:
DJD(> This patch added two new tests, RecoveryAfterBackup and
DJD(> RecoveryAfterBackupSetup, both of which are being run
DJD(> without a SecurityManager due to the noSecurityManager=true
DJD(> in their _app.properties files.
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12362691 ]
Daniel John Debrunner commented on DERBY-298:
-
This patch added two new tests, RecoveryAfterBackup and
RecoveryAfterBackupSetup, both of which are being run without
I have committed the most recent patch for this issue as svn 367352.
Øystein Grøvlen wrote:
"MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I just got back. I'll look at committing this, but would like to
MM> wait for Suresh to review.
The new version of the patch, derby-298b
> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I just got back. I'll look at committing this, but would like to
MM> wait for Suresh to review.
The new version of the patch, derby-298b.diff, that has been uploaded
should address issues raised by Suresh in his latest review.
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12361817 ]
Øystein Grøvlen commented on DERBY-298:
---
Suresh,
You are right that with my latest version of the patch,
getLogRecorEnd() will only return INVALID_LOG_INSTANT when the sc
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12361808 ]
Suresh Thalamati commented on DERBY-298:
Øystein ,
I reviewed the latest patch, it looks good. But I could not understand why
you would need the following check ?
I just got back. I'll look at committing this, but would like to
wait for Suresh to review.
Øystein Grøvlen wrote:
I finally got back to this issue hat have been laying around for way
too long. I have attached a new patch to JIRA that should address
Suresh's review comments. Could someone ple
I finally got back to this issue hat have been laying around for way
too long. I have attached a new patch to JIRA that should address
Suresh's review comments. Could someone please review it?
--
Øystein
> "ØG" == Øystein Grøvlen (JIRA) writes:
ØG> [
http://issues.apache.org/ji
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12361100 ]
Øystein Grøvlen commented on DERBY-298:
---
The recently attached patch (derby-298a.diff) addresses Suresh's
review comments. The only major change from the previous patch i
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12315919 ]
Øystein Grøvlen commented on DERBY-298:
---
Suresh,
The intent is that the new log file should be recognized after a log switch,
regardless of what log records may have bee
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12315265 ]
Suresh Thalamati commented on DERBY-298:
Hi Øystein,
I could not understand from the changes, If the new log file will be
recognized in the following two cases:
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12313185 ]
Øystein Grøvlen commented on DERBY-298:
---
This is further discussed in the following thread:
http://thread.gmane.org/gmane.comp.apache.db.derby.devel/4170
My current view
> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> If possible I would like to see a solution that does not
MM> depend on a special log record being first in the new log. At
MM> the level of specific log files, it does not know much about
MM> log records. It would be ni
Mike Matrigali wrote:Any requirement to put a specific log record "next"
in the stream is
I believe currently log recordsare being written to the in memory log buffer
while the switch is
happening (suresh, is this right?).
Not to the log buffers (in LogAccessFile.java) that are common to
If possible I would like to see a solution that does not depend on a
special log record being first in the new log. At the level of specific
log files, it does not know much about log records. It would be nice if
anything that dealt with log records just saw them as a single sequence
of log recor
> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> As you suggest I think there needs to be some way for recovery to
MM> determine a successful log switch has happened and to not log to the
MM> old file. I don't think a log record for the switch works as you need
MM> to
Øystein Grøvlen wrote:
"ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes:
ST> derby has two types of log files , one that works in RWS mode with a
ST> preallocated log file ,
What is RWS mode?
RWS mode is writing transction log using the write sync mechanism
supp
comments below
Øystein Grøvlen wrote:
"MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I spent some time thinking about this and I think the dummy record
MM> approach works in the current system assuming the code is as follows:
MM> o request for roll forward backup starts
> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I spent some time thinking about this and I think the dummy record
MM> approach works in the current system assuming the code is as follows:
MM> o request for roll forward backup starts
MM> o all subsequent write request
> "ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes:
ST> derby has two types of log files , one that works in RWS mode with a
ST> preallocated log file ,
What is RWS mode?
ST> and one which uses file sync with out preallocation. In case of
ST> preallocation , zero
Øystein Grøvlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_66168
]
Øystein Grøvlen commented on DERBY-298:
---
Looking at the code, I became a bit confused about the definition of an empty
log file. Scan.
I spent some time thinking about this and I think the dummy record
approach works in the current system assuming the code is as follows:
o request for roll forward backup starts
o all subsequent write requests suspended
o log switch initiated by backup request
o dummy record written
o backup takes
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_66209 ]
Øystein Grøvlen commented on DERBY-298:
---
On second thoughts, recovery after an OS-command backup is not an issue since
the database will be shut down when the backup is
[
http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_66168 ]
Øystein Grøvlen commented on DERBY-298:
---
Looking at the code, I became a bit confused about the definition of an empty
log file. Scan.getNextRecordForward contains de
26 matches
Mail list logo
