[ ORACLE ][ STRUTS ] [ JAVA ] maximum open cursor

Version imprimable

27/04/2004, 17h42
LoulouFifi

[ ORACLE ][ STRUTS ] [ JAVA ] maximum open cursor
Bonjour,

J'ai une appli en Struts sous Tomcat 4.1 avec Oracle 8.1

J'ai testé sur une petite base en dev et mes requetes marchent nickel pas de pb...mais en prod les tables sont plus importantes (plus de données)
et je rencontre une erreur de ce type sur une requete toute con :
Code:

1 2 SELECT * FROM PRODUIT
Ca me jette une SQLException avec ce message dans ma log :
Code:

1 2 ORA-01000: maximum open cursors exceeded
le truc c'est que j'ai qu'un ResultSet qui parcourt les enregistrements
en dev, cette meme requete me retourne genre 50 enregistrements,
mais en prod il m'en retourne 150 (ca doit etre ca)
du coup qu'est ce que je dois faire pour que ma requete passe et que donc il m'affiche et me traite mes 150 enregistrement retourné sans me lancer d'erreur. Car en prod, mes requetes vont toujours traiter un nbre importants de données (pas comme en dev...)
Je suis dans l'urgence (l'appli marche po en prod:!!)

merci de m'aider
27/04/2004, 17h52
RanDomX

Tu parcours avec un curseur ?

C bad practise ca !!!
27/04/2004, 18h20
LoulouFifi

non c'est un ResultSet avec un getStatement, executeQuery...etc
j'utilise pas de cursors...

mais je crois c'est parce la requete me renvoit trop de données car quand c'est 50 enregistrment ca passe tres bien...
mais des que ca dépasse la centaine ca me génère cette erreur...
27/04/2004, 21h12
RanDomX

Franchement 150 c pas enorme, mets les bons index et ca devrait passer tout seul.
27/04/2004, 21h43
knotty

explique un peu mieux,

depuis sqlplus, tu fais
select * from produit

, et ca te donne ce message?

ou bien c'est plus complique que ca?

Le message est clair, tu es a cour de curseurs, ca peut venir d'un tas de trucs, par exemple que tu en laisses ouverts, ou que ta requete est plus compliquee que juste un select.

select count(*) from v$open_cursor, ca dit quoi?

Bon courage
27/04/2004, 22h01
LoulouFifi

En fait j'ai mon appli web (page JSP avec des traitements java qui font appel a une base Oracle)
ma connexion se met bien en place, pas de pb a ce niveau (driver, déclaration de la datasource OK)
J'ai testé mon appli en base de test c'est ok

et en prod, l'utilisateur doit se connecter via un ecran web (premiere écran de l'appli) cette requete (vérification du login et du password en base) s'execute correctement, l'utilisateur est identifié et il va sur une page d'accueil. Avant ca, j'ai un traitement qui va rechercher des données pour alimenter mes combo list (genre une liste de produit, une liste de clients...Etc) et c'est a cette requete que ca me génère une SQLException et donc que ca fait planter l'appli.
car pour alimenter ma combo list, mon code java execute une requete avec executeQuery (tout ce qui a de plus standard) du genre
executeQuery("select * from PRODUIT");
et c'est la que ca a l'air de planter car quand cette requete doit me retourner plus de 100 produit benh ca me met cette erreur de curseurs,
je pense donc qui a un truc qui limite mes renvois de données car quand je dois retourner moins d'une centaine cette meme requete passe tres bien...
mais comment récupérer plus d'une centaine d'enregistrement sans avoir cette erreur?

= /
27/04/2004, 22h02
LoulouFifi

comment ca mettre des bon index??
ou ? comment?
comprend po...
27/04/2004, 22h19
knotty

montre le morceau de code qui fait la requete.

T'as essaye select count(*) from v$open_cursor ?
27/04/2004, 22h23
LoulouFifi

J'ai pas le code sous la main...
mais c'est tout con :
je réupère un Statement de la connection
je fais statement.executeQuery(sql) qui me renvoie un ResultSet je parcours ensuite celui ci pour récup les données
et apres je ferme le statement et le resultset..

mais demain j'envoie ca

et aussi le select count open cursor

merci

a demain

voila mon code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	public Collection selectIdNomProduit()  throws TechnicalException {
		try{
			String sql = "select ID_PRODUIT, LL_NOM from EGADM.T_PRODUIT ORDER BY LL_NOM ASC";
 
			return select(sql);
		}
		catch(SQLException s){
			System.out.println("log - SQLException - AccueilHome/selectIdNomProduit : " + s.getMessage());
			throw new TechnicalException("Erreur Technique  Serveur indisponible");
		}
 
	 }

La requete est executé par la méthode select :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
   protected Collection select(String sql) throws SQLException {
	 Connection c = null;
	 Statement s = null;
	 ResultSet r = null;
	 try {
	  	c = DBManager.dbManager.getConn();
	  	s = c.createStatement();
	  	r = s.executeQuery(sql);
	   	Collection collection = new ArrayList();
	   	while(r.next())
			 collection.add(get(r));
	   	return collection;
	 }finally{
	   if(r!=null)try{r.close();}catch(SQLException uncatched){}
	   if(s!=null)try{s.close();}catch(SQLException uncatched){}
	 }
   }

Vous remarquerez que tout est bien fermé....mais j'ai cette erreur ORA

Autre j'ai essayé de faire :

Code:

1
2
 
select count(*) from v$open_cursor

mais il ne semble pas connaitre v$open_cursor

28/04/2004, 11h08
RanDomX

Citation:

Vous remarquerez que tout est bien fermé

Je ne vois pas de releaseConn depuis ton DBmanager !!!

Est ce que tu remets tes connections ds le pool de temps en temps ?

si au début de ma classe Action
je fais un :

Code:

1
2
3
4
5
6
7
 
/**
 * Connection à la base
 */
DataSource dataSource = (DataSource)(getServlet().getServletContext().getAttribute("macciiDS"));
Connection con = dataSource.getConnection();
DBManager.dbManager.setConn(con);

macciiDS étant ma dataSource définit dans mon struts-config.xml

et a la fin de la classe Action avant de faire un forward vers la page jsp je ferme la connection :

Code:

1
2
3
 
 
DBManager.dbManager.closeConn();

ma classe DBManager :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
public class DBManager {
		  /***
                   * Element static DBManager
                   */
	  public static DBManager dbManager = new DBManager();
 
		  /****
                   * Connection a la bd 
                   */
	  public Connection conn = null;
 
	 	 /***
                   * Constructeur
                   */
	  public DBManager(){			
	  }
 
		  /****
                   * Sauvegarde la connection pour la page (valable pour une classe Action)
                   */
	  public void setConn(Connection c){
			conn = c;
	  }
 
	  /****
           * Retourne la connection
           * @return la connection pour la page Action
           */
	  public Connection getConn()throws SQLException{
		if (conn == null){
			throw new SQLException("getConn() : Pas de Connection valide");
  		  }
  		  return conn;
	  }
 
	  /****
           * Ferme la connection à la base de données
           *
           */
	  public void closeConn(){
	  	try{
	  	  	if(conn!=null)
	  		  	conn.close();
	  	}
	  	catch(SQLException s){
	  		System.out.println("log - SQLException - DBmanager : "+s.getMessage());
	  	}
	  }
 
 
}

comment ca mettre les connections ds le pool de temps en temps?
comment on fait ca?
ze comprend pas...

28/04/2004, 12h18
LoulouFifi

Bon le open_cursor de mon fichier init.ora est initialisé a 300....

le truc c'est que quand je teste en local localhost (mais mon appli se connecte a la base de données en prod) ca marche pas de pb de cursors

mais quand je teste sur le serveur (l'appli est déployé sur le serveur se connectant a la meme base) benh la, ca me met l'erreur!!!

je comprends plus rien...

pourquoi me fait-il une erreur sur le serveur mais pas en local alors que les paramètre de connection à la DataSource sont les memes (meme base, meme user, meme password...tout pareil...)

de l'aide....
siouplait
28/04/2004, 14h52
knotty

faut bien voir que ca doit etre un truc idiot.

pourquoi une difference entre ta machine de prod et de dev, peut etre parce que il n'y a plus de curseurs sur la machine prod, quelqu'un d'autre l'utilise peut etre. D'ou le select que je te demande. On en aura le coeur net.

Sinon,

while(r.next())
collection.add(get(r));

Que fait la methode get ? (code stp)

Code:

1
2
3
4
5
6
7
8
9
10
 
 
protected Object get(ResultSet r) throws SQLException {
    return new Combo(r.getString(1),   // l'id 
                                r.getString(2));  //le nom 
}
 
tout simplement...
 
Combo est un objet String String avec juste ses méthodes get et set

30/04/2004, 14h55
LoulouFifi

Re,

Bon, je vais poster une réponse car évitera surement plus d'un à galérer comme j'ai galérer...
En fait, si ca marchait en local et pas sur le serveur alors que ma base était la meme (celle de prod) mais que l'appli (la meme) sur le serveur me retournait cette erreur Oracle sur des requetes toute con :

select * from Produit

et que j'avais bien vérifié que je fermais tout pour ces requetes
r.close(); et s.close() = ResultSet et Statement

C'est parce que (attention ...suspense...)...ailleurs je fermais pas toujours mes ResultSets (bouuuuuuuuuuuuuuh.........oui, oui vous pouvez huer...)
Et en fait, moi, je restais fixer sur cette requete alors que c'est ailleurs que ca merdait!!
pourquoi ?
parce qu'en fait sur la requete ou je fermais pas mon ResultSet (ct une requete balèze) du coup ca bouffait tous les curseurs....et comme en test je rédémarre mon serveur Tomcat...je relibère tout....et donc je m'apercois pas de cet oubli...
Par contre en prod, il redémarre pas le serveur...donc a un moment donné ca sature...et meme la requete qui est bien codé...benh elle passe pas...

Conclusion :

Faut toujours regarder partout qu'on a tout bien fermer (dans des clause finally de préférence) aussi bien les Statements que les ResultSet

Je sais...vous me l'avez dit....

Merci a tous

Bon voila pour mes aventures...je mets le tag Résolu et on en reparle plus...

oufff.....

:wink:
30/04/2004, 15h28
knotty

bouhhh... Decevant... :(

Sans rire, la morale, c'est que jdbc c'est complique, et facile de faire des erreurs.
Considere l'utilisation de qqchose comme Spring Framework, qui evite tous ces problemes.

Ou bien un O/R comme hibernate, jdo ou toplink.

Enfin, considere l'utilisation d'un debuggueur ou profiler, ton ide prefere devrait en avoir un integre.

Bon courage
06/08/2009, 10h28
temoanatini

v_$open_cursors

... juste pour dire (vu que je suis actuellement sur le même genre de pb) que la vue v_$open_cursors ne donne pas la liste des curseurs ouverts à un moment donné (comme son nom ne l'indique pas) mais la liste de curseurs cachés
ah! Oracle, parfois quand tu nous tiens, on a envie que tu nous lâche un peu...

5 ans après je me trouve confronté au même problème...

La seule différence est que j'utilise oracle 10g... Ben oui on a évolué en 5 ans.... :)

Je pense avoir fermé toutes mes requêtes, résultset et conenctions dans la clause finaly:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
		finally
		{
			if (pstmt1 != null)
			{
				try
				{
					pstmt1.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing statement",e);
				}
			}
			if (pstmt2 != null)
			{
				try
				{
					pstmt2.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing statement",e);
				}
			}
			if (pstmt3 != null)
			{
				try
				{
					pstmt3.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing statement",e);
				}
			}
			if (rs1 != null)
			{
				try
				{
					rs1.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing Resultset",e);
				}
			}
			if (rs2 != null)
			{
				try
				{
					rs2.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing Resultset",e);
				}
			}
			if (rs3 != null)
			{
				try
				{
					rs3.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing Resultset",e);
				}
			}
			if (con != null)
			{
				try
				{
					con.close();
				}
				catch (SQLException e)
				{
					request.getSession().getServletContext().log("Exception when closing Connection",e);
				}
			}
		}

Dès que je dépasse un certains nombres d'objets sélectionnés, j'ai une page blanche (donc pas de résultats affichés) et une belle erreur dans mon fichier de log:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
java.sql.SQLException: ORA-01000: maximum open cursors exceeded
 
	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
	at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
	at oracle.jdbc.ttc7.Oopen.receive(Oopen.java:120)
	at oracle.jdbc.ttc7.TTC7Protocol.open(TTC7Protocol.java:587)
	at oracle.jdbc.driver.OracleStatement.open(OracleStatement.java:558)
	at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2786)
	at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)
	at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:536)
	at be.gim.matriceCadastrale.web.actions.DonneesCadastralesAction.execute(DonneesCadastralesAction.java:87)
	at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
	at com.livinglogic.struts.workflow.TilesWorkflowRequestProcessor.processActionPerform(TilesWorkflowRequestProcessor.java:158)
	at com.livinglogic.struts.workflow.WorkflowRequestProcessorLogic.process(WorkflowRequestProcessorLogic.java:568)
	at com.livinglogic.struts.workflow.TilesWorkflowRequestProcessor.process(TilesWorkflowRequestProcessor.java:179)
	at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
	at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at moreservlets.filters.CompressionFilter.doFilter(CompressionFilter.java:66)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:534)

Quelqu'un peut-il m'aider?

Merci

29/01/2010, 13h39
Mercenary Developer

Obtenir statment a partir du ResultSet

Bonjour,

Code:

resultSet.getStatement().close();

Ca ne marche pas ?

Cordialement.
30/03/2011, 11h40
Mr.Java

En règle générale, en Java, quand un objet est hors de portée, il est automatiquement garbage collector, mais la spécification Java ne place pas toutes les exigences spécifiques de la JVM sur le moment (ou même si) cela se produira pour un objet particulier. Par conséquent, ne comptez pas sur finaliseurs (finally) de fermer vos curseurs.

Explicitement ferment tous les curseurs à l'aide soit par ResultSet.close (), Statement.close (), et / ou PreparedStatement.close () lorsque vous n'avez plus besoin du curseur. Cela garantit que les curseurs côté serveur correspondant sont fermées, empêchant l'ORA-1000 erreur. N'oubliez pas de fermer ces objets JDBC dans le cadre qu'ils ont été créés. La fermeture de ces objets dans un bloc {} enfin est toutefois recommandé, ne comptez pas sur une méthode finally (), car une méthode finally () n'est jamais garanti à courir par la JVM!

Une erreur fréquente survient lorsque CallableStatement est utilisée pour appeler une procédure PL / SQL qui retourne un REF CURSOR. Si vous ne fermez pas l'objet correspondant ResultSet, un curseur sera laissé ouvert sur le serveur.
30/03/2011, 11h52
fr1man

Je pense qu'il y a confusion entre la méthode finalize et le bloc finally.
Il n'y aucun danger à fermer ses connexions, curseurs dans un bloc finally, bien au contraire. On est certain que ce bloc sera exécuté en cas d'exception, ou pas.

En revanche, on est jamais certain de l'appel de la méthode finalize, donc effectivement, il faut éviter d'y mettre du code de libération de ressources.