Hi,
Your post and work around not using persistent timer helped me a lot. I
also have just experienced the same problem with v3.1.2 Open Source Edition.
Here is how to recover the corrupted EJB__TIMER__TBL.
I am posting this for everyone's interest who come accross this problem.
1) Delete EJB Timer application from the GlassFish(GF) server.
2) Create a new JavaDB database with the same name as GlassFish uses.
Put the following code anywhere in your GlassFish server(J2EE) application.
Any server application running on GF should recognize the "jdbc:derby"
scheme.
Connection conn;
try {
conn = DriverManager.getConnection(
"jdbc:derby:C:/temp/ejbtimer;create=true"
);
} catch(SQLException se) {
for (SQLException e = se; e != null; e =
e.getNextException()) {
System.err.printf("%s: %s%n", e.getSQLState(),
e.getMessage());
}
}
3) Stop GF server and delete the original ejb-timer JavaDB from the following
location. Be sure to make backup before deletion!
[GlassFIsh Intall Dir]\glassfish\domains\domain1\lib\databases\ejbtimer
4) Then using 'ij' program located in the directory [GlassFIsh Intall
Dir]\javadb\bin, create the EJB__TIMER__TBL in the newly created JavaDB that
the default set up of GF uses for EJB Timer.
>ij
ij>connect
'jdbc:derby:c:/glassfish3/glassfish/domains/domain1/lib/databases/ejbtimer';
ij>CREATE TABLE "APP"."EJB__TIMER__TBL" ("TIMERID" VARCHAR(255) NOT NULL,
"APPLICATIONID" BIGINT, "BLOB" BLOB(2147483647),
"CONTAINERID" BIGINT, "CREATIONTIMERAW" BIGINT, "INITIALEXPIRATIONRAW"
BIGINT, "INTERVALDURATION" BIGINT,
"LASTEXPIRATIONRAW" BIGINT, "OWNERID" VARCHAR(255), "PKHASHCODE"
INTEGER,"SCHEDULE" VARCHAR(255), "STATE" INTEGER);
ij>exit;
5) Now you can restart GF and should have no locking (or persistence of it)
problem.
--
[Message sent by forum member 'satoc']
View Post: http://forums.java.net/node/850201