RE: Lock on database file not being released...
Hi, I did as you said and adjusted those values for the odbc. Same result. The database file is still showing as locked. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:11 AM To: 'Tomcat Users List' Subject: RE: Lock on database file not being released... In the ODBC connection entry in the registry, or by using the ODBC Connection editor, change those two parameters. They are probably set for Yes and should be set to No. If you are not using an ODBC Connection entry, then you need to pass these as arguments in the connection string. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:07 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... How do I do that in server.xml file? Is that what you are suggesting? Specifying other parameters for the connection pooling? Please elaborate on what you think I should do. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:28 PM To: 'Tomcat Users List' Subject: RE: Lock on database file not being released... OK, I now think I know the issue. Try changing the entries for the ODBC connection. Specifically change: ImplicitCommitSync And UserCommitSync The docs are inconsistent on their usage, and I think the drivers vary depending upon the version of the Jet engine you are using. Anyhow, adjust these and see what happens. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
At this point, I would have to say the answer is to get a real database. FWIW, I use access in our application and except for the ImplicitUserSync and UserCommitSync issue have never really had any problems. Of course you could be running into problems specific to your version of Java, or Jet. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 8:43 AM To: Tomcat Users List Subject: RE: Lock on database file not being released... Hi, I did as you said and adjusted those values for the odbc. Same result. The database file is still showing as locked. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:11 AM To: 'Tomcat Users List' Subject: RE: Lock on database file not being released... In the ODBC connection entry in the registry, or by using the ODBC Connection editor, change those two parameters. They are probably set for Yes and should be set to No. If you are not using an ODBC Connection entry, then you need to pass these as arguments in the connection string. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:07 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... How do I do that in server.xml file? Is that what you are suggesting? Specifying other parameters for the connection pooling? Please elaborate on what you think I should do. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:28 PM To: 'Tomcat Users List' Subject: RE: Lock on database file not being released... OK, I now think I know the issue. Try changing the entries for the ODBC connection. Specifically change: ImplicitCommitSync And UserCommitSync The docs are inconsistent on their usage, and I think the drivers vary depending upon the version of the Jet engine you are using. Anyhow, adjust these and see what happens. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
A common problem in beginner JDBC is not performing a ROLLBACK when an update fails. Even when autocommit is set to TRUE, a failed update will leave the records locked in the database. Update statements should always be coded so that if an exception is thrown, a rollback is performed on the connection. -Original Message- From: SH Solutions [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 10:51 AM To: 'Tomcat Users List' Subject: AW: Lock on database file not being released... Hi However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. cu Steffen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
One other question. What is the setting of AutoCommit? Are you setting it to TRUE? -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
One other question. What is the setting of AutoCommit? Are you setting it to TRUE? It's not touched, i.e., it's default, which is true. All I am doing in my jsp is doing a regular select * from tableName. Nothing fancy. Returns 2 rows that are in that table. I am just testing this out first and that's why it's so simple for now. So, no updates are being done. Nothing. Just one select. Yet, it still locked the database file after the server is shut down. I am shutting down the server with the shutdown script that came with the download. Ideas? Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lock on database file not being released...
Hi, Is your jsp/servlet forwarding or redirecting to another jsp/servlet/html page before close() is called on the connection? Dreamweaver will automagically create jsp pages that fall prey to this gotcha. If you have access to the log files, log the opening and closing of the connection, and see if what you think is happening is in fact happening. Sean - Original Message - From: George Sexton [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:15 PM Subject: RE: Lock on database file not being released... One other question. What is the setting of AutoCommit? Are you setting it to TRUE? -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
No, it's not doing any of that at all. I am attaching my welcome.jsp for reference. It's extremely simple code there. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Sean Utt [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 9:11 PM To: Tomcat Users List Subject: Re: Lock on database file not being released... Hi, Is your jsp/servlet forwarding or redirecting to another jsp/servlet/html page before close() is called on the connection? Dreamweaver will automagically create jsp pages that fall prey to this gotcha. If you have access to the log files, log the opening and closing of the connection, and see if what you think is happening is in fact happening. Sean - Original Message - From: George Sexton [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:15 PM Subject: RE: Lock on database file not being released... One other question. What is the setting of AutoCommit? Are you setting it to TRUE? -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
Sorry, but for some reason the welcome.jsp didn't get attached to the previous email. Trying again. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Sean Utt [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 9:11 PM To: Tomcat Users List Subject: Re: Lock on database file not being released... Hi, Is your jsp/servlet forwarding or redirecting to another jsp/servlet/html page before close() is called on the connection? Dreamweaver will automagically create jsp pages that fall prey to this gotcha. If you have access to the log files, log the opening and closing of the connection, and see if what you think is happening is in fact happening. Sean - Original Message - From: George Sexton [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:15 PM Subject: RE: Lock on database file not being released... One other question. What is the setting of AutoCommit? Are you setting it to TRUE? -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
Ok, I don't know why, but it's not letting me attach it.
I am pasting it here in this email:
-
%@ page import=javax.naming.* %
%@ page import=javax.sql.* %
%@ page import=java.sql.* %
html
body
%
try
{
Context ctx = new InitialContext();
if(ctx == null ) throw new Exception(Boom - No Context);
DataSource ds =
(DataSource)ctx.lookup(java:comp/env/jdbc/afecWEBDB);
out.println(DataSource is: + ds);
if (ds != null)
{
out.println(ds is NOT null);
Connection conn = ds.getConnection();
out.println();
out.println(Connection is: + conn);
if(conn != null)
{
out.println(Connection is not NULL);
out.println();
Statement stmt = conn.createStatement();
out.println(Statement is: + stmt);
ResultSet rst = stmt.executeQuery(select * from
Users);
while(rst.next())
{
out.println(Record Found!);
out.println(br/);
out.println(rst.getString(1));
out.println(rst.getString(2));
out.println(br/);
}
log(THIS IS TEST! CONNECTION IS ABOUT TO BE
CLOSED!***);
rst.close();
stmt.close();
conn.close();
}
}
}
catch(Exception e)
{
System.out.println(NO LUCK!);
e.printStackTrace();
}
%
h1Hello THERE!/h1
/body
/html
---
Yaakov Chaikin
Software Engineer
BAE SYSTEMS
301-838-6899 (phone)
301-838-6802 (fax)
[EMAIL PROTECTED]
-Original Message-
From: Sean Utt [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 07, 2003 9:11 PM
To: Tomcat Users List
Subject: Re: Lock on database file not being released...
Hi,
Is your jsp/servlet forwarding or redirecting to another
jsp/servlet/html
page before close() is called on the connection?
Dreamweaver will automagically create jsp pages that fall prey to this
gotcha. If you have access to the log files, log the opening and
closing of
the connection, and see if what you think is happening is in fact
happening.
Sean
- Original Message -
From: George Sexton [EMAIL PROTECTED]
To: 'Tomcat Users List' [EMAIL PROTECTED]
Sent: Sunday, December 07, 2003 1:15 PM
Subject: RE: Lock on database file not being released...
One other question. What is the setting of AutoCommit? Are you
setting
it to TRUE?
-Original Message-
From: Chaikin, Yaakov Y (US SSA)
[mailto:[EMAIL PROTECTED]
Sent: Sunday, December 07, 2003 2:13 PM
To: Tomcat Users List
Subject: RE: Lock on database file not being released...
However, I have used this driver before in a standalone app and
when
you
close a connection, it certainly does release the lock on the
database
file.
This makes me think, you didn't use pooling in this standalone
app.
Therefor
check weather you close all your ResultSets and Statements. In
standalone
apps where no pooling is involved, they are caught by the garbage
collector,
but not in connection pooling.
Trapped into this myself.
Steffen,
I tried what you said and closed the ResultSet and Statement before
I
close the Connection. Still same affect.
Any other ideas anyone?
I highly doubt it's the driver. I would bet that I am doing
something
wrong. I just can't figure out what it is.
Thanks,
Yaakov.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lock on database file not being released...
Chaikin, Yaakov Y (US SSA) wrote: Ok, I don't know why, but it's not letting me attach it. I think the list discards attachments . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
Well, I've sent server.xml files over before and it went through. I am a bit confused about the attachment policy now. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Kwok Peng Tuck [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 9:53 PM To: Tomcat Users List Subject: Re: Lock on database file not being released... Chaikin, Yaakov Y (US SSA) wrote: Ok, I don't know why, but it's not letting me attach it. I think the list discards attachments . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lock on database file not being released...
Hmm, I could be wrong as well.. Chaikin, Yaakov Y (US SSA) wrote: Well, I've sent server.xml files over before and it went through. I am a bit confused about the attachment policy now. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Kwok Peng Tuck [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 9:53 PM To: Tomcat Users List Subject: Re: Lock on database file not being released... Chaikin, Yaakov Y (US SSA) wrote: Ok, I don't know why, but it's not letting me attach it. I think the list discards attachments . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
OK, I now think I know the issue. Try changing the entries for the ODBC connection. Specifically change: ImplicitCommitSync And UserCommitSync The docs are inconsistent on their usage, and I think the drivers vary depending upon the version of the Jet engine you are using. Anyhow, adjust these and see what happens. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
How do I do that in server.xml file? Is that what you are suggesting? Specifying other parameters for the connection pooling? Please elaborate on what you think I should do. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:28 PM To: 'Tomcat Users List' Subject: RE: Lock on database file not being released... OK, I now think I know the issue. Try changing the entries for the ODBC connection. Specifically change: ImplicitCommitSync And UserCommitSync The docs are inconsistent on their usage, and I think the drivers vary depending upon the version of the Jet engine you are using. Anyhow, adjust these and see what happens. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lock on database file not being released...
In the ODBC connection entry in the registry, or by using the ODBC Connection editor, change those two parameters. They are probably set for Yes and should be set to No. If you are not using an ODBC Connection entry, then you need to pass these as arguments in the connection string. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:07 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... How do I do that in server.xml file? Is that what you are suggesting? Specifying other parameters for the connection pooling? Please elaborate on what you think I should do. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:28 PM To: 'Tomcat Users List' Subject: RE: Lock on database file not being released... OK, I now think I know the issue. Try changing the entries for the ODBC connection. Specifically change: ImplicitCommitSync And UserCommitSync The docs are inconsistent on their usage, and I think the drivers vary depending upon the version of the Jet engine you are using. Anyhow, adjust these and see what happens. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
