Re: turn derby loggin off?
Mario Ernst wrote: hi, I try to start a tomcat / derby environment completely from CD. For this reason, I think the logging needs to be turned off (cause CD is not writeable). Is there any possibility to do so? Or is there another solution? Thanks and regards... You will find the info you need in the Developer's Guide, under Creating Derby databases for read-only use: http://db.apache.org/derby/docs/10.1/devguide/cdevdeploy15325.html -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/ ~~~ CONFIDENTIALITY NOTICE: If you are not the intended recipient of this email message, then I guess I am to blame for sending it to you in the first place. ~~~
Re: Why are classpath databases always read-only ?
Maybe you could explain how this would work? Are you assuming that the war/ear file is always unpacked into the local file system? Is that guaranteed for a J2EE server? No I cannot assume that, but if (and my guess it should be possible to determine where a resource loaded from the classpath came from, e.g. whether the URL contains a jar: protocol) then this would work. And if not, it can obviously not be written. But for servlet containers like Tomcat and Jetty, one can ensure that the web app is unpackaged before it is started. Even if the web app is exploded, are you sure that the web app has write access to the directory to which the servlet container has exploded it? I'm not saying it doesn't, I just wouldn't be surprised if some container didn't want the contents of that directory to change. I don't think using an absolute path to the db is awfully ugly as long as it can be configured, e.g. as a context-param. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Recursive Select for Discussion Forum
Michael Segel wrote: On Wednesday 30 November 2005 12:42, Rick Hillegas wrote: Hi Michael, You could streamline your recursive walk by using a temporary table and a database procedure. The temporary table would hold the ids you recursively harvest. It would be populated by your database procedure, which would walk up the levels of your hierarchy. When the procedure returned, you could then join the temporary table to your discussion_item table to get the details you needed. It's not an elegant solution, but by running the procedure inside the database, you would eliminate a lot of network handshaking. Derby does not support hierarchical queries. You're welcome to log an enhancement request for this feature. Well if you're going to use Temp tables, why not go outside of just SQL statements and then use cursors? By using prepared statements you could do this and maybe use a little bit of recursion. Since this is SELECT, you'd want to make sure that you do this out side of a Transaction. (Transactions and recursive SQL statements can get messy.) Pretty straight forward from there. You only need to prepare two statements, and each recursion requires a unique resultSet to be declared. Your table would look like this: Table foo: msg_id int -- (you can autogenerate or use long or something else depending on # of messages and retension rules.) parent_id int (set default to 0) msg_author ... msg_header ... msg_txt ... Then create an index on msg_id and also on parent_id; This can be done a couple of ways or permutations. Here's the simplest. Make the following CLASS variables; A database connection con; Create a vector to store the result sets. int rec_lvl = 0 (this is the level of recursion) Create and prepare the following select statement: SELECT msg_id, msg_author, msg_header, msg_txt FROM foo WHERE parent_id = ? ORDER BY msg_id; You then have two methods to write: 1) A Method to pull the data out of the result set, and pop it on to a vector, including the rec_lvl variable. (This will be used to build your tree) 2) The recursive method that finds all the children to the input value of parent_id. So the first time you call the method you pass in the value of 0 for the parent id. Then for each record you get back, you pass the result set to the popOnVector and the current rec_lvl value. You then call the recursive routine, passing in the current msg_id and (rec_lvl + 1); Thats all it takes. When presenting a discussion thread, there are typically two things you want to take into account: * Ordering of messages * Indentation Ordering: * All replies to a specific message (messages having a 'parent') should be displayed directly under that parent message. * Within a sub-group of messages, sharing the same parent, messages should be ordered on its timestamp. Indentation: * Every message which has a parent should be more indented than the parent. * Every message having the same distance to the root message (the one without a parent) should have the same indentation. With the current table definitions I have seen suggested here, neither of these can be computed dynamically with a single, non-recursive SQL query. The indentation part is easy: Don't compute it dynamically, store it in the table. Whenever you add a new record to the table, you know the id of the parent message. The indentation level for the record to be inserted is the parent's indentation level plus one. The ordering part is more tricky. What information do we have in each record that can be used for ordering. message id - most likely monotonically increasing with each message added (chronologically) parent id indentation level timestamp - this one is, like the message id, monotonically increasing, so it does not add any information for us to use when sorting So the table is (wrt sorting) a set of triplets: (message_id, parent_id, indentation). For a database to sort this set, it must be able to look at two random triplets and determine which of those comes first, without considering other triplets that may be in the set. Is this possible? As an example, look at these two triplets: (8,3,2) (7,6,3) Which comes first? It's impossible to tell, since it depends on the values of other rows. Consider these two message trees: (1,null,0) - root message (2,1,1) - 2nd message received, 1 is parent, indentation is 1 (4,2,2) - Received after message 3 below, but is reply to 2 (3,1,1) (8,3,2) (5,1,1) (6,5,2) (7,6,3) Here, (8,3,2) comes before (7,6,3), because of the subgroups they belong to. (1,null,0) (2,1,1) (6,2,2) (7,6,3) (3,1,1) (8,3,2) (4,1,1) (5,1,1) Here, (7,6,3) comes before (8,3,2). So I think you don't get the complete ordering for free from SQL, you'll have to do some of the sorting in your java code. It should be possible to do with a 1-pass algorithm, I think. -- Oyvind Bakksjo Sun Microsystems, Database Technology
Re: I need advice for Table schema Design.
Legolas Woodland wrote: Hi Thank you for reading my post. I need your advice for a design/query problem. Scenario : Imagine that i should design a system which should be able log and process view / hit over banners. So , in some portion of time there is a high rate of click / view over one banner , this could be fake because web site owner can produce fake traffic on his/site to earn more money. I think this is a rather complex problem to solve, as this kind of fraud has become more sophisticated. There was a presentation about this at the VLDB conference this year, I have included links to the paper and the presentation. Hope that helps a little. http://www.vldb2005.org/program/paper/tue/p169-metwally.pdf http://www.vldb2005.org/program/slides/tue/s169-metwally.ppt
Re: What does next Exception mean?
Stefan Schuster wrote: Hi, I get an error: SQL Exception: Failed to start database 'e2emappingdb', see the next exception for details. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) What is meant by next Exception ? The cause ? The exception arising with the next call ? The next exception I see in my log/project/life ? ;) http://java.sun.com/j2se/1.4.2/docs/api/java/sql/SQLException.html#getNextException() :) BTW: Is there a way to search through this mailing-list via an web interface (I already found the web-interface that allows browsing, but I cant find a search field) I think most people use Google... :o) Yes, I know, it's not adequate. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Derby and portability
Daniel John Debrunner wrote: As you say in the first paragraph, database portability is a *feature* of Derby and thus it should be in the documentation (DERBY-711, thanks Jean). Since it's a feature, I wouldn't expect to be in the charter, I think that's too much detail. That's ok. Charter or not, as long as there's a written commitment to it somewhere, it's fine. :) -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Derby and portability
The Derby Project Charter (on the web site) states that it should be Pure Java, but it does not say anything about portability for anything but the _code_. Can one, for example, safely assume that the on-disk database format is platform-independent? I have read it somewhere, but I don't see it in the charter, so do I have a guarantee that this is an invariant? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Spaces in the database name with the client driver
Daniel Noll wrote: We had issues a while ago with having spaces in the name of the database when using the embedded driver. These have been fixed, but... I've just found that there is an issue when using the *client* driver with databases that have spaces in their name. Is there some kind of workaround for this issue? As it's a URL we're supposed to specify, I tried using %20 but that didn't work anyway. I also tried modifying the URL parsing code in the ClientDriver class but that results in a network protocol error. Hi Daniel, did you get any replies on this? Did you find a workaround? I know others have hit this problem too, so I created DERBY-708 for this issue. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Question about using URLClassLoader and Derby
David W. Van Couvering wrote: Hi, Kathey. At first glance it looks good to me. I'm assuming *all* classes your app needs are available to the from the URL you specify, because you are not specifying a parent classloader when you create it. Not specifying a parent classloader does not mean that there will not be one. When using this constructor, the parent classloader will be the default classloader at the invocation point, e.g. the same classloader that would be used if you wrote Class.forName() at that spot. Also, you'll need to make sure you give the class that runs this code the permission to load classes (I'm not sure exactly how this is done, I just know it's an issue). But I am no classloader guru. I am forwarding this to folks I know within Sun who have done a *lot* of work within classloaders as part of the app server effort. I'll get back to you with any information I get. David Kathey Marsden wrote: My goal is: I want to use a specific version of Derby which I ship with my app and I don't want to interfere with any other derby versions loaded in the same JVM or have them interfere with me. I am creating a new datasource in a separate URLClassLoader and using that for creating all my connections. Are there other things I need to do to meet my goal? Your URLClassLoader will delegate loading to its parent before it tries to load anything itself. You need to be sure that your URLClassLoader's parents have no Derby system to load - if they do, the result is not what you want. If you cannot assume anything about what's in the parent classloaders' search path, you will need to create your own custom classloader which cuts off the delegation for classes whose names follow a certain pattern - for instance, start with org.apache.derby. I have done this successfully in other projects. I have a feeling it all must be more complex than it looks to me right now. Just a little. :) -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/ ~ CONFIDENTIALITY NOTICE: If you are not the intended recipient of this email message, then I guess I am to blame for sending it to you in the first place. ~
Re: Question about using URLClassLoader and Derby
Kathey Marsden wrote: Super neat! To summarize: I can keep other Derby versions loaded from interfering with my app by creating a DerbyURLClassLoader that overrides the loadClass method to filter out any Derby classes in the parent class loader. I can prevent my app from interfering with other Derby versions by loading Derby in a separate DerbyURLClassLoader and creating a DataSource from there that I use for all my connections as described in my original mail. I have a completely isolated environment with regard to Derby. Because JDBC provides a single entry point at the DataSource, I don't have to understand the overall ClassLoader hierarchy or otherwise be a ClassLoader expert. Does anyone see any holes here? As long as the code you have using Derby is accessing Derby objects through the JDBC interfaces/classes, everything should be fine. If, however you have code explicitly referencing Derby class names (whether it is EmbedStatement, EmbeddedDataSource etc.), you should be aware that a class X loaded with class loader A is not the same class as a class X loaded with class loader B (class loaders are name spaces). Code which explicitly references Derby classes must be loaded with the same class loader as the Derby classes themselves, otherwise you'll get strange exceptions. But as said, when your client code simply uses the JDBC interfaces/classes, there should be no problems. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Note B: If you're running with autocommit OFF, you should definately not use the same connection object in multiple simultaneous requests (either use synchronization or create multiple connections). This is true even with automcommit on. Multiple threads using the same connection with ResultSets will mess with each other, as per the JDBC sprc. An executeQuery by one thread will close any ResultSet any other thread is processing. Could you elaborate on this? I created a small test program which Prepares two statements in separate threads, but uses the same connection object. I execute statement A and read a few rows from the resultset in thread 1, execute statement B and read a few rows from it in thread 2, do a little interleaved reading, then read the rest of the rows from both resultsets in their respective threads. Got no exception, indicating that no result set was closed. I ran this in autocommit mode in both embedded and client/server mode. Code excerpt below, in case my explanation of the test program was unclear: t1.prepareStatement(); t2.prepareStatement(); t1.executeQuery(); t1.showRow(); t1.showRow(); t1.showRow(); t2.executeQuery(); t2.showRow(); t2.showRow(); t2.showRow(); t1.showRow(); t2.showRow(); t1.showAll(); t2.showAll(); I have seen some differing behaviour with respect to this in client/server and embedded mode before (that's why I made the test), but I couldn't reproduce any issue now. --- JDBC 3.0 - Section 10.1. A commit occurs when a statement is complete in auto-commit mode. For Select statements, the statement is complete when the associated result set is closed. The result set is closed as soon as one of the following occurs: ... another Statement object is executed on the same connection So in your example the call to t2.executeQuery() should cause a commit on the connection which will close the ResultSet for t1. Your code probably has ResultSets which are held HOLD_CURSORS_OVER_COMMIT (which is the default) and thus are not closed by the commit. You're right, after changing this to CLOSE_CURSORS_AT_COMMIT I got exceptions. In addition I guess you showRow() does a next() and then the rs.gerXXX()? I think if you called t2.executeQuery() between a next() and the rs.getXXX() calls on the other thread, I think you will see problems. I tried that, but that did not change any behaviour. Besides, why would it? It doesn't seem logical to me why you would get an exception exactly there, if the resultset isn't closed and you don't get an exception on the subsequent next() and rs.getXXX() calls after the second execute. Thus sharing connections across threads is just problematic unless the application performs synchronization and/or has very good knowledge of what others threads are doing at all times. Any application will just be less error prone if it uses separate connections for separate threads, isn't one of the reasons to use a relational database to not have to worry about data synchronization issues? This of course is not specific to Derby, the JDBC spec specifies this behavviour. I agree. Just to be clear, I am not arguing that anyone should code applications that way, I'm just trying to figure out exactly how Derby behaves. Although sharing connections between unrelated threads which perform different tasks is not a good idea, I can imagine there are cases where one would benefit from having multiple open resultsets on a connection with autocommit off. This should be allowed, right? Also, Derby should be agnostic to whether these result sets are processed in different threads. Actually, this is what I do in jdbcapi/SetQueryTimeoutTest.java, in order to verify that the correct statement is affected by the timeout when multiple statements are executing concurrently. What's strange is that this works in embedded mode but fails in client/server mode (I'm about to submit an implementation of setQueryTimeout for the client driver). The little test program I wrote yesterday works in both modes, however. I don't see what I'm doing differently - in both programs I have autocommit off, HOLD_CURSORS_OVER_COMMIT (by default), and have two threads that prepare and execute a select query on the same connection, then traverse the result sets. Still one program gets a closed resultset in client/server mode, the other doesn't. I must be overlooking something. Any ideas? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
[EMAIL PROTECTED] wrote:
Daniel John Debrunner wrote:
My thinking is that the executeQuery() will cause a commit which will
cause the open held ResultSet used by the other thread to move off the
row, as required by the SQL standard. Thus before any getXXX() call can
be made, the held cursor needs to be re-positioned using next(). I think
you have said before that Derby doesn't act this way, though looking at
the embedded code it should.
So I tried the following:
conn.setAutoCommit(true);
Statement st1 = conn.createStatement();
try {
st1.execute(drop table t1);
} catch (SQLException e) {
// Ignore
}
st1.execute(create table t1 (a int));
st1.execute(insert into t1
values(0),(1),(2),(3),(4),(5),(6));
PreparedStatement ps1 = conn.prepareStatement(select * from
SYS.systables,
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY,
ResultSet.HOLD_CURSORS_OVER_COMMIT);
PreparedStatement ps2 = conn.prepareStatement(select * from
t1,
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY,
ResultSet.HOLD_CURSORS_OVER_COMMIT);
ResultSet rs1 = ps1.executeQuery();
ResultSetMetaData md1 = rs1.getMetaData();
rs1.next();
show(rs1, md1);
rs1.next();
ResultSet rs2 = ps2.executeQuery();
ResultSetMetaData md2 = rs2.getMetaData();
show(rs1, md1);
rs2.next();
show(rs2, md2);
rs2.next();
show(rs2, md2);
rs1.next();
show(rs1, md1);
rs2.next();
show(rs2, md2);
(The show method calls ResultSet.getString on all columns.)
As you can see, the second executeQuery() call is between rs1.next() and
show(rs1, md1). There's no exception thrown - no need to reposition, it
seems. I changed the prepareStatement for ps1 to use
CLOSE_CURSORS_AT_COMMIT, and then I got an exception about the result
set being closed, so there's definitely a commit made at the second
executeQuery.
I think I am finally beginning to grasp what is going on here. :)
---
JDBC 3.0 - Section 10.1.
A commit occurs when a statement is complete in auto-commit mode.
For Select statements, the statement is complete when the associated
result set is closed. The result set is closed as soon as one of the
following occurs:
...
another Statement object is executed on the same connection
Reading this from the bottom and up, what happens when running with
CLOSE_CURSORS_AT_COMMIT is that executing the other statement causes the
first result set to be closed, causing the statement to complete,
causing the transaction to commit.
Now, if we have HOLD_CURSORS_OVER_COMMIT, we don't want the result set
to be closed after the commit. But since closing the result set is what
triggers the commit, it would mean that the result set would first have
to be closed (in order to trigger the commit) and then, after the
commit, to not be closed after all! What I suspect is that when we have
specified HOLD_CURSORS_OVER_COMMIT, the second execute does not close
the result set in the first place (and here the spec quote above is
vague, it does not state anything about holdability), thus never causing
a commit.
Quite funny, then, that whether the second execute triggers a commit
depends on the holdability of other result sets.
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
Legolas Woodland wrote: Hi Thank you for the Blog entry , but i could not understand how i should do the integration based on your blog comment. I tried Integration senario from developerWorks , I need it for a real world high transaction system (23-30 Tra / second) so i think developersWork scenario is not good for me. can you explain more pleas ? (to Oyvind Bakksjo) You should be able to fully embed Derby into your web application without any need to configure your servlet container *and* get decent performance by doing the following: * Place derby.jar in your web application's lib directory. * Use derby in embedded mode inside your application (use jdbc:derby:dbname[;attributes...] as the connection url) * For performance, you need to avoid creating a new connection with each request. Therefore, you should a) boot the database when your web application is loaded (and shut it down when the web app is unloaded) and b) reuse existing connection(s). * To do a) - create a class in your web app which implements the javax.servlet.ServletContextListener interface (see http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletContextListener.html). The class should have a public no-arg constructor. Say, the class is called MyListener. - Inside the web-app section of your deployment descriptor, add listenerlistener-classMyListener/listener-class/listener. - The class must implement two methods. In contextInitialized(), you boot the database by getting a connection to it (possibly with ;create=true, if necessary). Stuff that connection aside for later use by calling 'sce.getServletContext().setAttribute(derbyconnection, connection);'. In contextDestroyed, fetch the existing connection (with 'sce.getServletContext().getAttribute(derbyconnection);') and close that connection. Shut down the database by connecting again with the shutdown=true attribute in the url. * To do b) - When a request is received (say, HttpServlet.doGet() is invoked), you get the existing connection by calling 'getServletContext().getAttribute(derbyconnection);'. Use this connection for your database work. Note A: You may want to create and use more than one connection to increase performance if you have many simultaneous requests. Note B: If you're running with autocommit OFF, you should definately not use the same connection object in multiple simultaneous requests (either use synchronization or create multiple connections). I hope this helps. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Note A: You may want to create and use more than one connection to increase performance if you have many simultaneous requests. I would not recommend a single connection for any simultaneous requests. Note B: If you're running with autocommit OFF, you should definately not use the same connection object in multiple simultaneous requests (either use synchronization or create multiple connections). This is true even with automcommit on. Multiple threads using the same connection with ResultSets will mess with each other, as per the JDBC sprc. An executeQuery by one thread will close any ResultSet any other thread is processing. If you are running Derby embedded then the cost of creating a connection per request will be much lower than traditional client server databases, and most likely will be a small fraction of the cost of the query or update. That's true, as long as the database is not booted shut down with each request. That was the case in the prototype integration described in the referred article. As long as the database is booted shut down only in the context listener class, it should be fine to create new embedded connections with each request. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Note B: If you're running with autocommit OFF, you should definately not use the same connection object in multiple simultaneous requests (either use synchronization or create multiple connections). This is true even with automcommit on. Multiple threads using the same connection with ResultSets will mess with each other, as per the JDBC sprc. An executeQuery by one thread will close any ResultSet any other thread is processing. Could you elaborate on this? I created a small test program which Prepares two statements in separate threads, but uses the same connection object. I execute statement A and read a few rows from the resultset in thread 1, execute statement B and read a few rows from it in thread 2, do a little interleaved reading, then read the rest of the rows from both resultsets in their respective threads. Got no exception, indicating that no result set was closed. I ran this in autocommit mode in both embedded and client/server mode. Code excerpt below, in case my explanation of the test program was unclear: t1.prepareStatement(); t2.prepareStatement(); t1.executeQuery(); t1.showRow(); t1.showRow(); t1.showRow(); t2.executeQuery(); t2.showRow(); t2.showRow(); t2.showRow(); t1.showRow(); t2.showRow(); t1.showAll(); t2.showAll(); I have seen some differing behaviour with respect to this in client/server and embedded mode before (that's why I made the test), but I couldn't reproduce any issue now. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
Michael Segel wrote: On Monday 31 October 2005 14:40, Susan Cline wrote: As Jean mentioned, if you use the Prototype integration option of the article you can have the derby jar files in the war file. I think you can just replace the war file with the new web application that contains the derby jar file(s) in the lib directory without stopping the Tomcat server. I think Tomcat sees new war files (possibly depending on how it is configured) when they are placed in the webapps directory. Susan Replace the file? I would be very suspect if that were the case. Usually your application will open a file descriptor to the files at start up. (Your new files don't have the same inode (whatever the Microsoft analogy is ...) So its not the same file. This would mean that you would have to refresh Tomcat to get it to see the new file. Now if you can refresh Tomcat, then you should have the power to start and stop Tomcat. If you mean add it to the directory and then have Tomcat discover the new files/apps that would be different. This is what the Tomcat website says about hot deployment of web applications: Deploying on a running Tomcat server It is possible to deploy web applications to a running Tomcat server. If the Host autoDeploy attribute is true, the Host will attempt to deploy and update web applications dynamically, as needed, for example if a new .WAR is dropped into the appBase. For this to work, the Host needs to have background processing enabled which is the default configuration. autoDeploy set to true and a running Tomcat allows for: * Deployment of .WAR files copied into the Host appBase. * Deployment of exploded web applications which are copied into the Host appBase. * Re-deployment of a web application which has already been deployed from a .WAR when the new .WAR is provided. In this case the exploded web application is removed, and the .WAR is expanded again. Note that the explosion will not occur if the Host is configured so that .WARs are not exploded with a unpackWARs attribute set to false, in which case the web application will be simply redeployed as a compressed archive. * Re-deployment of a web application if the /WEB-INF/web.xml file (or any other resource defined as a WatchedResource) is updated. * Re-deployment of a web application if the Context Descriptor file from which the web application has been deployed is updated. * Re-deployment of a web application if a Context Descriptor file (with a filename corresponding to the Context path of the previously deployed web application) is added to the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. * Undeployment of a web application if its document base (docBase) is deleted. Note that on Windows, this assumes that anti-locking features (see Context configuration) are enabled, otherwise it is not possible to delete the resources of a running web application. Note that web application reloading can also be configured in the loader, in which case loaded classes will be tracked for changes. My interpretation is that it is actually possible to just replace the .war file. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: I need some advice to choose database for an upcomming job
Jean T. Anderson wrote: [EMAIL PROTECTED] wrote: ... I would like to suggest reading my (short but excellent ;o) blog entry, where I describe how one can do lifecycle management in a standard (container-agnostic) way, which neither requires access to the Tomcat configuration nor stopping/starting the server. http://weblogs.java.net/blog/bakksjo/archive/2005/09/embedding_the_a_1.html Is this link to your blog entry persistent, Oyvind? --if I add it to the Derby web site, will it still be good 6 months from now? Yes, I think blog entries on java.net should be persistent. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: paging Øyvind and Naka
Rick Hillegas wrote: Hi Øyvind and Naka, I think you both may be working on fixing the same problem: the broken regression tests. The tests were broken by the fix to bug 330 and now Naka has filed bug 663 against the test problems. You might want to coordinate your efforts here. Naka filed DERBY-663 and assigned it to me, so I've committed a fix to it. I have run the jdbcapi testsuite with no failures and I'm now waiting for derbyall to finish. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Backup on-line
Edson Carlos Ericksson Richter wrote: There is a plan to implement backup on line (with read/write active, not only read)? Yes, this is recorded in Jira as issue DERBY-239 and is being actively worked on. You can watch the derby-dev mailing list to monitor the progress of this activity. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Starting Derby at boot time on linux
Johan Wasserman wrote: How do I start Derby at boot time on linux? I used the startup script provided (startNetworkServer.ksh) and linked it to S99derby in rc5.d but get the message Could not listen on port 1527 on host start... Kind regards... I don't know of course, but it could be that you already have a process occupying that port. Try running the command below: netstat --tcp -l -p --numeric-ports | grep 1527 -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: derby performance and 'order by'
Rick Hillegas wrote: Thanks for the pointer to this presentation, Oyvind. It's a pretty startling observation though I'm not sure how to use it. I'd be interested in hearing your thoughts about this some time. The question raised in this presentation is whether the optimizers in the databases examined (Oracle, DB2 and SQL Server) are actually too clever, evaluating (in some cases) 100+ query plans for a single query when simply changing the selectivity on two relations. The assumption is that they could evaluate far less plans and still perform well. Now, in Derby, I think we're still on the opposite side - we should probably investigate more optimization techniques and execution plans, as this thread has shown. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: derby performance and 'order by'
Rick Hillegas wrote: Hi Oyvind, I agree that this is inelegant. As you note, this approach step by step forces a plan which the current Derby optimizer is capable of considering--with or without the covering index. Regardless of whether we teach the optimizer some better tricks, I think it's worth beefing up our support for in-memory temporary tables: o There are always deceptively simple queries which the optimizer misjudges. It's good to give the customer tools for getting unstuck while they wait for the bugfix release. o Often the customer knows facts about the data which the optimizer can't plausibly learn. Yes, I agree with you. o The current Derby optimizer is capable of considering only a very limited subset of the useful plans. That reminds me of a very entertaining presentation which was held at VLDB this year: Slides: http://www.vldb2005.org/program/slides/fri/s1228-reddy.ppt Paper: http://www.vldb2005.org/program/paper/fri/p1228-reddy.pdf Have a look, it's worth the time. We should definitely consider more execution plans in Derby, so that we, too, could draw such interesting pictures. ;o) -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: derby performance and 'order by'
Rick Hillegas wrote: It might help to add another column to the index so that it covers both the restriction and the ordering information. And if we could add a primary key to a temporary table, then something like the following might take us in the right direction: create index time_index on orders( time, orderID ); declare global temporary table session.ztemp ( orderID varchar( 50 ) primary key ) not logged; -- all the information we need is in the index so there's no need -- to probe the base table insert into session.ztemp select orderID from orders where time between '10/01/2002' and '11/30/2002' ; -- hopefully the temporary table didn't have to spill to disk. -- no sort should be needed for this query and you can just -- stop siphoning out rows after you get the first 1000. select l.* from orders l, session.ztemp r where l.orderID = r.orderID order by orderID; If I understand this correctly, you're here relying on the fact that the primary key constraint on the temporary table creates an underlying index, so the records inserted can be read out in sorted order. This is also a form of sorting. Shouldn't the engine be able to use similar techniques in the execution of the original query, without relying on the user splitting up the query, creating temporary tables etc.? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: How to compute the duration of two timestamps
Kostas Karadamoglou wrote: Hi, How can I compute the duration of two timestamps? Is there any built-in function that helps? Are any alternative options? This question was asked on this list not so long ago. You can find the answer in the mailing list archives: http://mail-archives.apache.org/mod_mbox/db-derby-user/200508.mbox/[EMAIL PROTECTED] -- Øyvind Bakksjø Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: remote connections to embedded derby
Knut Anders Hatlen wrote: James Cowan [EMAIL PROTECTED] writes: Hi is it possible to make remote connections to an embedded derby database? No, you'll have to run the the network server. However, the network server is just a layer of networking code on top of an embedded derby database, so in some sense you can say it makes it possible to make remote connections to an embedded database. But that wasn't what you had in mind, I guess... Isn't it? http://db.apache.org/derby/docs/10.1/adminguide/cadminovntsrvsample.html Quote: The embedded driver is loaded when the Network Server is started. The JVM that starts the Network Server can obtain an embedded connection to the same database that the Network Server is accessing to serve clients from other JVMs. This solution provides the performance benefits of the embedded driver and also allows client connections from other JVMs to connect to the same database. To illustrate this in beautiful ascii-art (best viewed with fixed font width): +--+ | Client JVM | | ++ | | | Your application logic | | | ++---+ | | | | | V | | +--+ | | |Network Client JDBC driver| | | +-++ | | | | +---|--+ | +---|--+ | Server JVM| | | ++| | | | Your application logic || | | ++---+| | | |V | | |++ | | V| Network Server | | | +-+--+-+ | | |Embedded JDBC driver| | | | ++ | | | | Derby engine| | | +--+ | +--+ -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: derby jdbc load driver
Satheesh Bandaram wrote: I think Derby recommends using *.newInstance()* to load JDBC drivers... In fact, it is required if you plan to shutdown and reboot databases on the same thread/VM for Derby. Take a look at the javadoc for EmbeddedDriver. Ok. But if Derby recommends it, then it should be explicitly mentioned in the manuals (both in the Reference and the Developer's Guide), which it isn't: http://db.apache.org/derby/docs/10.1/devguide/cdevdvlp40653.html http://db.apache.org/derby/docs/10.1/ref/rrefjdbc32052.html Instead, there are contradicting statements like the one below: --- * Class.forName(org.apache.derby.jdbc.EmbeddedDriver) Our recommended manner, because it ensures that the class is loaded in all JVMs by creating an instance at the same time. --- What instance? Since there is no .newInstance() here, this can be understood as if the class has a static initializer which creates an instance of the class. And if so, why should the application do .newInstance()? -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
