Hi Kathey:
Yes, it is schemachange2. I need the same Id in attach table because it
is a foreign key of inbox. I don't know how getGeneratedKeys work. Does it get
the same key in inbox? Since delete thread will delete data in inbox table, the
id in inbox table will keep changing as test run. Thank you so much for looking
at this with me.
Lily
Sent from my iPhone
On Jul 25, 2009, at 11:40 AM, "Kathey Marsden (JIRA)" <[email protected]> wrote:
[
https://issues.apache.org/jira/browse/DERBY-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735310#action_12735310
]
Kathey Marsden commented on DERBY-4166:
---------------------------------------
Lily in the schemachange2 patch I still see the attachments in a separate loop
from the mail and we still have the SELECT ID from REFRESH.INBOX which may be
causing the deadlock. Did getGeneratedKeys() not work to get the id if you
keep the attachment insert in the loop? I think if we do that and commit
after completing the full insert of each mail into INBOX and ATTACH we
shouldn't see timeouts or deadlocks.
improvements to the mailjdbc test
---------------------------------
Key: DERBY-4166
URL: https://issues.apache.org/jira/browse/DERBY-4166
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.6.0.0
Reporter: Kathey Marsden
Priority: Minor
Attachments: DERBY-4166-databasesize.diff, Derby-4166-samedb.diff,
DERBY-4166-schemachange.diff, DERBY-4166-schemachange2.diff, Derby-4166.diff
When recently working with the mailjdbc system test
org.apache.derbyTesting.system.mailjdbc on DERBY-4152 I noticed some potential
improvements that might be good for the test. We should probably hold off on
these improvements however until the root cause of DERBY-4152 is established,
however, so we don't muddy the waters with that issue by changing the test.
1) DbTasks.moveToFolders may throw an IllegalArgumentException.
There is a line: message_id = Rn.nextInt(count - 1);
if count is 1 the argument to nextInt() might be 0 which is not allowed. I
hit this once but lost the stack trace, but it is apparent that when there is
only one row in the table this can occur.
2) Allow/implement multiple attachments per message and cleanup
DbTasks.insertMail() logic.
- Remove the attach_id column from INBOX to allow multiple attachments.
-Make the attachment insert part of the message for loop in insertMail.
Use getGeneratedKeys() to get the id of the inserted message.
When attachments are inserted, insert (1-4) attachments and give them a
corresponding attach_id from 1-4.
This will allow for removal of the select statements used to determine id and
attach_id. I'll file another issue for these improvements if folks agree that
they are sensible.
A detailed description of the current implementation of insertMail is described
at
https://issues.apache.org/jira/secure/attachment/12405685/insertMailSummary.txt
3) DbTasks.databaseSize calculation is wrong. It doesn't match du -sk. The
method does not recurse into subdirectories and includes the length() on
directory files which is undefined accourding to the file.length() javadoc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
