InstantDB Project
About InstantDB
Project Mail Lists
Short History
Reporting Bugs
Screen Shots
3rd Party Examples
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

Peter Hearty wrote:
 
> It could be that the RmiJdbc driver isn't releasing the connection. If
> that's the case then table locks might remain from the previous application
> (as far as IDN knows - if the Connection's still there then so is the
> application).
> 
> Try setting up a timeout using Statement.setQueryTimeout(). That way, if the
> app fails, the transaction should time itself out.

Sorry, I don't want to be boring, but I need to solve this problem as
soon as possible (quickly!!! :-)
I tried to use the setQueryTimeout() as you said, but it didn't work. 
The crash of my application is obviously simulated (just System.exit(1)
in the right point) to test the
robustness of my application. Since it is a stafull application, I use a
db to mantain the state. Moreover there are more istance of the same
application that use the same db.
Before the crash I close the statement, but I don't close the
connection, and when the crashed application is restarted, it seems to
work fine, since it meets the first query. Then it stops and
doesn't give back control to my application.To tell the true, I tested
this situation a lot of time, keeping the other istances of the
application idle, in order to prevent  concurrency conflict.

Thanks,

bye.
-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe instantdb" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-instantdb@enhydra.org.