If you don't have Connection - how can you get PreparedStatement?

What objects - just parameters?
Serialize parameters and SQL string and reuse it later.
Kind of:
class SavedStatement{
  private String sql;
  private Object[]params;
  ....
}

PreparedStatement is an interface... so assuming the existing program was
written correctly (by declaring its variables using the interface type, and
not any concrete type), you could create a new class which wraps any
PreparedStatement (the one you get from your JDBC driver) into a new, more
functional PreparedStatement containing your new "database not available
transparency layer".

I'm no database expert, but are you 110% sure that adding such a "lets defer
our interactions to this database" layer makes sense? As with many
apparently clever ideas, it may actually not make any sense after closer
inspection. I don't know. I'll leave this question to others to ask/answer.

   Yeah, I can't think of an "easy" way to solve this problem either. What
I recommend is you look into the "Command" design pattern. Basically, you
create a class called Command which encapsulates a particular action that
the user wants performed. You would put these commands into a queue, and
periodically check if the DB is available. If it is, you dequeue the first
command in the queue and execute it.

   The idea is to abstract above the level of SQL statements so that the
infrastructure using the Command objects do not need to worry about the
state of the database when the command executes; rather the Command objects
should make no assumptions about the state of the DB, and set everything up
itself.

   - Oliver

I would step a layer backwards. Encapsulate all updates in command
objects. This will also help you serialize updates that require multiple
statements. With control of the command object implementation you can do
what you like.

Tom Hawtin

Hi Chris. You are essentially describing a local DBMS to store
what you will eventually propagate to the SQLServer when it
comes back. You might consider one of the all-Java and/or
free local DBMSes to store whatever updates you want to do
but can't, and when you can, retrieve the local-stored data and
update the real DBMS.
Joe Weinstein at BEA Systems

Look at the disconnected JDBC RowSet:
http://today.java.net/pub/a/today/2004/10/15/jdbcRowsets.html

Yakov Fain
http://www.weekendwithexperts.com

Use something that is always available, like Derby or MYSQL, then sync
the two at your convenience.

I think you are best to think about this in terms of the application,
forgetting SQL entirely. Think of your packets that you save as
commands or work units in terms of your application, not SQL updates.
Then write a transaction replay that reads the packets and may do
several SQL commands, varying what it does based on the results.

In other words your interface to live SQL or Memorex SQL is the same,
and the interface is application-centric rather than SQL centric. This
gives you most flexibility to deal with faking the missing live SQL or
missing user during replay.

I would suggest creating a custom implementation of JDBC that wraps the
JDBC driver you are using.  This makes it transparent to the
application.  When the database is available, send requests to the
wrapper.  When it is not available, write requests to a file in a
convenient format (I suggest plain text, not serialization).

HTH,
Ray

It's a bit late, but I haven't seen any replies to this (possibly the result of
an over-full killfile ;-), so...

I'm assuming that you are not very concerned with data integrity here.  If not,
then you /have/ to use an architecture that (in some way) includes a
fully-featured database in a place that is always accessible to the application
(on the same box, perhaps), or else you will risk either loosing data or
applying data twice.  If you do need that then I'd look into "message queuing"
middleware.  Otherwise...

One way would be to store the SQL statement itself, plus a record of the values
of the parameters, as the persisted record.  From that you could "resurrect"
the prepared statement, fill in the parameters, and then execute it.  Probably
the easiest thing to do would be to replace all prepared statements in your
program with some sort of proxy that knows how to do this if the DB is not
present when told to commit().

Obviously there are improvements you could make to the scheme, but that's the
basic idea.

   -- chris