Re: [JBoss-dev] Optimisitic locking vs. the rest...
Hi Bill, just now I'll only pick up your table and complete what I can. Select for update supported --- Oracle YES 0) Sybase ? Informix ? DB2? Postgres ? mySQL ? BerkelyDB ? SQL Server ? Informix YES 1) MySQL MyISAM NO 2) MySQL BDB/BerkelyDB ?3) MySQL InnoDB YES 4) Sybase YES 5) SQL Server YES 6) 0) Oracle has 1 Option regarding waiting for the lock: SELECT ... FOR UPDATE NOWAIT 1) Informix has 2 Options regarding waiting for the lock: SELECT ... FOR UPDATE NOWAIT and SELECT ... FOR UPDATE WAIT time 2) MySQL non transactional table types only support a LOCK TABLE feature, which will isolate at the cost of drastically reduced concurrency. 3) Not documented, had no time to test. BDB is a transactional table type. See http://www.sleepycat.com/ or http://www.mysql.com/doc/B/D/BDB.html 4) InnoDB is a full transactional table type. The SELECT ... FOR UPDATE has no NOWAIT or WAIT option. InnoDB has deadlock detection. See http://www.innodb.com/ or http://www.mysql.com/doc/I/n/InnoDB.html 5) As of many open/closed problem reports (-:) and release bulletins on the Sybase site http://www.sybase.com/. 6) As of the same source as 5) regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata JawsEntityMetaData.java
User: deerwood
Date: 01/07/24 21:56:51
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
o Indentation and formatting according to project standards.
One spot found, where indentation does not match parser, possible Bug?
Authors, please review, I'm currently wearing the 'formatter' hat
(seemingly beeing too large, thus making me blind for any context :-)
Revision ChangesPath
1.13 +128 -86
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
Index: JawsEntityMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JawsEntityMetaData.java 2001/07/03 15:57:53 1.12
+++ JawsEntityMetaData.java 2001/07/25 04:56:51 1.13
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.ejb.plugins.jaws.metadata;
import java.util.ArrayList;
@@ -30,84 +31,88 @@
import org.jboss.logging.Logger;
/**
- * description
+ * description
*
- * @see related
- * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
- * @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
- * @version $Revision: 1.12 $
+ * @see related
+ * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
+ * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
+ * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
+ * @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
+ * @version $Revision: 1.13 $
*
* Revisions:
* 20010621 Bill Burke: made read-ahead defaultable in standardjboss.xml and
jaws.xml
*
-
*
*/
-public class JawsEntityMetaData extends MetaData implements XmlLoadable {
+public class JawsEntityMetaData
+ extends MetaData
+ implements XmlLoadable
+{
// Constants -
// Attributes
- // parent metadata structures
+ /** Parent metadata structure. */
private JawsApplicationMetaData jawsApplication;
+
+ /** Parent metadata structure. */
private EntityMetaData entity;
- // the name of the bean (same as entity.getEjbName())
+ /** The name of the bean (same as entity.getEjbName()). */
private String ejbName = null;
- // the name of the table to use for this bean
+ /** The name of the table to use for this bean. */
private String tableName = null;
- // do we have to try and create the table on deployment?
+ /** Do we have to try and create the table on deployment? */
private boolean createTable;
- // do we have to drop the table on undeployment?
+ /** Do we have to drop the table on undeployment? */
private boolean removeTable;
- // do we use tuned updates?
+ /** Do we use tuned updates? */
private boolean tunedUpdates;
- // do we use 'SELECT ... FOR UPDATE' syntax?
+ /** Do we use 'SELECT ... FOR UPDATE' syntax? */
private boolean selectForUpdate;
- // is the bean read-only?
+ /** Is the bean read-only? */
private boolean readOnly;
- // make finders by default read-ahead?
+ /** Make finders by default read-ahead? */
private boolean readAhead;
private int timeOut;
- // should the table have a primary key constraint?
+ /** Should the table have a primary key constraint? */
private boolean pkConstraint;
- // is the bean's primary key a composite object
+ /** Is the bean's primary key a composite object? */
private boolean compositeKey;
- // the class of the primary key
+ /** The class of the primary key. */
private Class primaryKeyClass;
- // the fields we must persist for this bean
+ /** The fields we must persist for this bean. */
private Hashtable cmpFields = new Hashtable();
- // the fields that belong to the primary key (if composite)
+ /** The fields that belong to the primary key (if composite). */
private ArrayList pkFields = new ArrayList();
- // finders for this bean
+ /** Finders for this bean. */
private ArrayList finders = new ArrayList();
- // the bean level datasource
-/**
- * This will now support datasources at the bean level. If no datasource
- * has been specified at the bean level then the global datasource is used
- *
- * This provides flexiblity for having single deployment units connecting to
- * different datasources for
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata FinderMetaData.java JawsApplicationMetaData.java
User: deerwood
Date: 01/07/23 09:28:46
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
FinderMetaData.java JawsApplicationMetaData.java
Log:
o Indentation and formatting to project standards.
Revision ChangesPath
1.5 +41 -29
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/FinderMetaData.java
Index: FinderMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/FinderMetaData.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FinderMetaData.java 2001/06/21 21:52:38 1.4
+++ FinderMetaData.java 2001/07/23 16:28:46 1.5
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.ejb.plugins.jaws.metadata;
import org.w3c.dom.Element;
@@ -15,71 +16,82 @@
/**
- * description
- *
- * @see related
- * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=[EMAIL PROTECTED]danch/a
- * @author a href=[EMAIL PROTECTED]Bill Burke/a
- * @version $Revision: 1.4 $
+ * description
+ *
+ * @see related
+ * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
+ * @author a href=[EMAIL PROTECTED]danch/a
+ * @author a href=[EMAIL PROTECTED]Bill Burke/a
+ * @version $Revision: 1.5 $
*
* Revisions:
* 20010621 Bill Burke: setReadAhead added.
*
*/
-public class FinderMetaData extends MetaData implements XmlLoadable {
+public class FinderMetaData
+ extends MetaData
+ implements XmlLoadable
+{
// Constants -
-
+
// Attributes
+
private String name;
private String order;
private String query;
-
+
/** do we perform 'read-ahead' of column values? (avoid making n+1 database
hits) */
private boolean readAhead = false;
-
+
// Static
-
+
// Constructors --
+
/** default constructor */
- public FinderMetaData() {
- }
-
- /** constructor used to provide non-defined finders (findAll, BMP style
-* finders) with their metadata. */
- public FinderMetaData(String name) {
+ public FinderMetaData() {}
+
+ /**
+* constructor used to provide non-defined finders (findAll, BMP style
+* finders) with their metadata.
+*/
+ public FinderMetaData(String name)
+ {
this.name = name;
}
-
+
// Public
+
public String getName() { return name; }
-
+
public String getOrder() { return order; }
-
+
public String getQuery() { return query; }
-
+
public boolean hasReadAhead() { return readAhead; }
public void setReadAhead(boolean newval)
{
readAhead = newval;
}
-
+
// XmlLoadable implementation
- public void importXml(Element element) throws DeploymentException {
+
+ public void importXml(Element element)
+ throws DeploymentException
+ {
name = getElementContent(getUniqueChild(element, name));
query = getElementContent(getUniqueChild(element, query));
order = getElementContent(getUniqueChild(element, order));
-
+
// read ahead? If not provided, keep default.
String readAheadStr = getElementContent(getOptionalChild(element,
read-ahead));
if (readAheadStr != null) readAhead =
Boolean.valueOf(readAheadStr).booleanValue();
- }
-
+ }
+
// Package protected -
-
+
// Protected -
-
+
// Private ---
// Inner classes -
1.9 +216 -178
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsApplicationMetaData.java
Index: JawsApplicationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsApplicationMetaData.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JawsApplicationMetaData.java 2001/06/27 03:55:36 1.8
+++ JawsApplicationMetaData.java 2001/07/23 16:28:46 1.9
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.ejb.plugins.jaws.metadata;
import
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws JPMInitCommand.java JPMStartCommand.java
User: deerwood
Date: 01/07/22 21:23:02
Modified:src/main/org/jboss/ejb/plugins/jaws JPMInitCommand.java
JPMStartCommand.java
Log:
o indentation to jboss project defaults
Revision ChangesPath
1.3 +3 -2 jboss/src/main/org/jboss/ejb/plugins/jaws/JPMInitCommand.java
Index: JPMInitCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JPMInitCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JPMInitCommand.java 2000/12/07 15:44:30 1.2
+++ JPMInitCommand.java 2001/07/23 04:23:02 1.3
@@ -11,11 +11,12 @@
* Interface for JAWSPersistenceManager Init Command.
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public interface JPMInitCommand
{
// Public
- public void execute() throws Exception;
+ public void execute()
+ throws Exception;
}
1.3 +3 -2 jboss/src/main/org/jboss/ejb/plugins/jaws/JPMStartCommand.java
Index: JPMStartCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JPMStartCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JPMStartCommand.java 2000/12/07 15:44:30 1.2
+++ JPMStartCommand.java 2001/07/23 04:23:02 1.3
@@ -11,11 +11,12 @@
* Interface for JAWSPersistenceManager Start Command.
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public interface JPMStartCommand
{
// Public
- public void execute() throws Exception;
+ public void execute()
+ throws Exception;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/bmp CustomFindByEntitiesCommand.java
User: deerwood
Date: 01/07/22 21:23:02
Modified:src/main/org/jboss/ejb/plugins/jaws/bmp
CustomFindByEntitiesCommand.java
Log:
o indentation to jboss project defaults
Revision ChangesPath
1.4 +34 -29
jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java
Index: CustomFindByEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CustomFindByEntitiesCommand.java 2001/05/27 00:49:15 1.3
+++ CustomFindByEntitiesCommand.java 2001/07/23 04:23:02 1.4
@@ -30,64 +30,69 @@
*
* @see org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntitiesCommand
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
-public class CustomFindByEntitiesCommand implements JPMFindEntitiesCommand
+public class CustomFindByEntitiesCommand
+ implements JPMFindEntitiesCommand
{
// Attributes
- protected Method finderImplMethod;// method implementing the finder
-
- protected String name;// Command name, used for debug trace
-
+
+ /** The method implementing the finder. */
+ protected Method finderImplMethod;
+
+ /** Command name, used for debug trace. */
+ protected String name;
+
// Constructors --
-
- /**
-* Constructs a JAWS command which can handle multiple entity finders
+
+ /**
+* Constructs a JAWS command which can handle multiple entity finders
* that are BMP implemented.
+*
* @param finderMethod the EJB finder method implementation
*/
public CustomFindByEntitiesCommand(Method finderMethod)
throws IllegalArgumentException
{
- finderImplMethod = finderMethod;
- // set name for debugging purposes
- name = Custom finder +finderMethod.getName();
+ finderImplMethod = finderMethod;
+ // set name for debugging purposes
+ name = Custom finder +finderMethod.getName();
- Logger.debug(Finder:+name);
+ Logger.debug(Finder:+name);
}
-
+
// JPMFindEntitiesCommand implementation -
public FinderResults execute(Method finderMethod,
- Object[] args,
- EntityEnterpriseContext ctx)
+Object[] args,
+EntityEnterpriseContext ctx)
throws java.rmi.RemoteException, FinderException
{
FinderResults result = null;
// invoke implementation method on ejb instance
try {
- // if expected return type is Collection, return as is
- // if expected return type is not Collection, wrap result in Collection
- if (finderMethod.getReturnType().equals(Collection.class)) {
- Collection coll =
(Collection)finderImplMethod.invoke(ctx.getInstance(),args);
+ // if expected return type is Collection, return as is
+ // if expected return type is not Collection, wrap result in Collection
+ if (finderMethod.getReturnType().equals(Collection.class)) {
+Collection coll =
(Collection)finderImplMethod.invoke(ctx.getInstance(),args);
result = new FinderResults(coll, null, null, null);
- } else {
- Collection coll = new ArrayList(1);
- coll.add(finderImplMethod.invoke(ctx.getInstance(),args));
+ } else {
+Collection coll = new ArrayList(1);
+coll.add(finderImplMethod.invoke(ctx.getInstance(),args));
result = new FinderResults(coll, null, null, null);
- }
+ }
} catch (IllegalAccessException e1) {
- throw new FinderException(Unable to access finder
implementation:+finderImplMethod.getName());
+ throw new FinderException(Unable to access finder
implementation:+finderImplMethod.getName());
} catch (IllegalArgumentException e2) {
- throw new FinderException(Illegal arguments for finder
implementation:+finderImplMethod.getName());
+ throw new FinderException(Illegal arguments for finder
implementation:+finderImplMethod.getName());
} catch (InvocationTargetException e3) {
- throw new FinderException(Exception in finder
implementation:+finderImplMethod.getName());
+ throw new FinderException(Exception in finder
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java
User: deerwood
Date: 01/07/22 21:57:28
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
CMPFieldMetaData.java
Log:
o Almost blindly applied JBoss project indentation and formatting rules.
Have to review exception handling.
Revision ChangesPath
1.8 +171 -108
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
Index: CMPFieldMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CMPFieldMetaData.java 2001/06/22 05:04:24 1.7
+++ CMPFieldMetaData.java 2001/07/23 04:57:28 1.8
@@ -26,16 +26,16 @@
import org.jboss.logging.Logger;
/**
- * This class holds all the information jaws needs to know about a CMP field
- * It loads its data from standardjaws.xml and jaws.xml
+ * This class holds all the information jaws needs to know about a CMP field.
+ * It loads its data from standardjaws.xml and jaws.xml
*
- * @see related
- * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
+ * @see related
+ * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.7 $
- *
+ * @version $Revision: 1.8 $
+ *
* Revison:
* 20010621 danch: merged patch from David Jenks - null constraint on columns.
*/
@@ -44,35 +44,33 @@
// Attributes
- // the entity this field belongs to
+ /** The entity this field belongs to. */
private JawsEntityMetaData jawsEntity;
- // name of the field
-private String name;
+ /** Name of the field. */
+ private String name;
- // the actual Field in the bean implementation
+ /** The actual field in the bean implementation. */
private Field field;
- // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
+ /** The jdbc type (see java.sql.Types), used in PreparedStatement.setParameter .
*/
private int jdbcType;
- // true if jdbcType has been initialized
+
+ /** True if jdbcType has been initialized. */
private boolean validJdbcType;
- // the sql type, used for table creation.
+ /** The sql type, used for table creation. */
private String sqlType;
- // the column name in the table
+ /** The column name in the table. */
private String columnName;
-
- // for table creation, whether to include not null constraint on column
+
+ /** For table creation, whether to include not null constraint on column. */
private boolean nullable = true;
-
- private boolean isAPrimaryKeyField;
+ private boolean isAPrimaryKeyField;
- /**
-* We need this for nested field retrieval.
-*/
+ /** We need this for nested field retrieval. */
private String ejbClassName;
/**
@@ -89,18 +87,21 @@
// Static
// Constructors --
- public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity) throws
DeploymentException {
+
+ public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity)
+ throws DeploymentException
+ {
this.name = name;
this.jawsEntity = jawsEntity;
// save the class name for nested fields
- ejbClassName = jawsEntity.getEntity().getEjbClass();
ejbClassName = jawsEntity.getEntity().getEjbClass();
+//-re- huh? twice is safer? ejbClassName =
jawsEntity.getEntity().getEjbClass();
try {
// save the class for nested fields
ejbClass =
jawsEntity.getJawsApplication().getClassLoader().loadClass(ejbClassName);
- field = ejbClass.getField(name);
+ field = ejbClass.getField(name);
} catch (ClassNotFoundException e) {
throw new DeploymentException(ejb class not found: + ejbClassName);
} catch (NoSuchFieldException e) {
@@ -116,6 +117,7 @@
// Public
+
public String getName() { return name; }
public Field getField() { return field; }
@@ -123,15 +125,21 @@
public int getJDBCType() {
if (! validJdbcType) {
// set the default
-if (field!=null)
+ if (field!=null)
+ {
jdbcType =
jawsEntity.getJawsApplication().getTypeMapping().getJdbcTypeForJavaType(field.getType());
-else{
-try{
-
Re: [JBoss-dev] new wait(1000) not good
Hi Bill, I'm also worried about this same scenario with the new locking stuff in the mainline. With notifyAll instead of just notify is there a chance to starve threads? With notify aren't you guarateed FIFO for lock contention, but you wouldn't be guaranteed with a notifyAll? notify does NOT guarantee FIFO awakening of threads: the docs explicitely state: | The choice is arbitrary and occurs at the discretion of the | implementation. i.e. a LIFO or whatever implementation might lead to starvation. notifyAll seems to be MUCH better as of the docs: | The awakened threads will compete in the usual manner with | any other threads that might be actively competing to | synchronize on this object; for example, the awakened threads | enjoy no reliable privilege or disadvantage in being the next | thread to lock this object. So every thread, if it was waiting before or just coming in fresh, has the same chance to get the lock and proceed, avoiding starvation. Bye Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] comments on new instance interceptors and locking
Hi Bill and Marc and all others, Bill: I looked over the new Entity Interceptors and locking and have a few comments My reverence to Bill for this excellent code review. And ditto to Marc for the excellent code to review. Most points you discuss I'm barely able to follow, not to mention suggestions. And the one point 'upsetting' me (not really) 'wait() vs. wait(some_time)' was cleared by Marc: in the testing phase he wants to see the hang, in production code there WILL be a timeout to protect against client introduced deadlock situations. Whats left to me? Just let you know, that I'm watching, what you are doing here, still learning; might be some big brother is watching you too, at last the whole world is looking at that, not literally at every code line, but at JBoss as a very good EJB server and focussing on usability. Marc to Bill: | hey thanks, I feel I am in a fighter plane and I am working on | oxygen supply, not much to breeze in that code so I am always | happy to see a fellow bomber plane fly by, feel less alone. Hey, Bill actually impresses me as a wingman (?), accompanying you as near as possible having an eye at your back! And remember, if you ever make it back to your base, there are others to feed you! If you get lost in the skyes, may be Bill catches you up. Bill concluded: I'll probably open up a different email thread on this, but maybe all the locks should be pulled out of EnterpriseContext and be managed by some LockManager. If multiple instances for option B and C is ever implemented(I'd like to tackle this), they'll have to use a different locking mechanism because you wouldn't be able to synchronize on ctx and ctx.getTxLock(). Yes, let's have multiple instances! I'll try to be a usefull member of the groundcrew for that. best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Hi danch, Does anybody know what databases are case sensitive WRT column and table names (or even keywords). I've never run into case sensitive SQL databases before. MySQL too is case sensitive on database, table and index names on a case sensitive file system (i.e. xNIX) with some table types especially the default MyISAM table type. The reason is, that they simply use the given name to generate a file path from it. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbosstest automated testing: Test hangs not detected. NOW AGAIN High Load
Hi Marc, almost done with the rewrite of the locking mechanisms.. Nice. the bug removed is the busywait bug of the previous leaky-lock but in all instance what we are looking for is hangs in *particular threads*. I really don't know how we can automate that. I'm not sure what you mean with *particular threads*, my only interpretation is: might it be, that the particular threads experience deadlock? Or might be, one of the threads blocks on something (i.e. IO), letting others wait for a long time? If these scenarios are what you mean, the 'classic' approach comes into mind: timeout, to break the locks. If in doubt, throw 'possible deadlock' to all participating transactions. A more sophisticated solution (inside one and the same server) would be immediate deadlock detection by keeping graphs of transactions accessing resources and checking them before actually blocking the next TX. I've no idiom/algorithm available off my head, but can do research on that by request. Fallback ever is timeout. If I'm off topic, please ignore or blame me. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, bean C is ISOLATION1 and D is ISOLATION2 my question is can we reconfigure connection D with the new stuff? Yes, at transaction start time you MAY call Connection.setTransactionIsolation(int level), the docs only note: 'This method cannot be called while in the middle of a transaction.' regards georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, Bill: |- Somebody had a great idea earlier of adding optimistic locking for |CMP/JAWS. Along with this feature, you could write a specialized |EntityInstanceInterceptor that did not do transactional locking with |commit Option 'A'. This would be great for beans that had |read-only invoked operations 90% of the time. I suggested that and did take the job implementing it (though I actually did no coding yet because I have to earn some money). Marc: yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional locking. ... WE NEED STABILITY IN FEATURES Yes, agreed. My suggestion was intended for the Rabbit Hole and originally meant to be used with commit options B/C in case there are multiple bean instances when Rabbit Hole is finished. Multiple instances would be not very usefull with pessimistic locking done on the DB, as the pessimistic behaviour (and locking waiting without a message) simply would remain viewed from the clients perspective. But maybe Bill is right, OL could be used with commit option A and single bean instances too? I'm not really sure ... no I don't think so, because then every TX is working on state possibly modified by another TX and, even worse, with one instance only the optimistic approach (based on the diff of the actual beans state and the state before TX.begin) will fail, as at commit time the 'old' state has to be set equal to the current state and the next concurrent TX committing will succeed, where it should see a 'you are too late to commit' exception! regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/threading/mbean Threads.java ThreadsMBean.java
Hi Marc,
seems you've checked in intermediate test code?
Should be as given below?
Added: src/main/org/jboss/test/threading/mbean Threads.java
ThreadsMBean.java
...
// get a random value between 1 and 100
int value = random.nextInt(100);
// 10% removal
- if (value 40) {
+ if (value 10) {
ejbTest.remove();
}
// 40% normal
- else if (value41) {
+ else if (value 50) {
ejbTest.test();
}
// 20% business exception
- else if (value42) {
+ else if (value 70) {
ejbTest.testBusinessException();
}
// 20 % runtime excpetion
else if (value 90) {
ejbTest.testRuntimeException();
}
// 10% timeout
else {
ejbTest.testTimeOut();
}
___ ___
| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/threading/mbean Threads.java ThreadsMBean.java
Hi, sorry for wasting bandwidth, I see, you've fixed it already. seems you've checked in intermediate test code? regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
want this isolation. It remains, the CMP code must enable setting the isolation level somehow to something other then the DB default. All in all, I think JBOSS should delegate synching and locking to the DB wherever it can because the DB is usually more efficient at this. Not sure how efficiently the DB really does it, but i.e. with Informix the DB locking is somewhat brain damaged (assuming I'm right with the above). Also, IMHO, this is really the best way to synch multiple instances of JBoss. Agreed, as long as JBoss doesn't do synching between several instances (no current plans to do that, as far as I know). Regards, Bill Sorry for being verbose again regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, David Jencks: I don't think I understand what you are suggesting. However... Just as a reminder, my suggestions for mimicked optimistic locking was: generate SQL for update/delete with a where clause not only using the primary key fields, but also the old values of changed fields / all fields; then interpret a '0 rows affected' response from executeUpdate() as you're to late, you must rollback and throw an Exception. Are you familiar with the lock-free versioning/ optimistic locking scheme used in interbase/firebird? transactions are numbered sequentially when they are started. I know, someone mentioned it before. Interbase does that at the database level, I assume, no need to have the TX ID in the EJB server/container/bean? My suggestion is meant for DB's, that don't have native optimistic locking support (and only mimickes OL, see one of my last mails with the diagram, showing pitfalls). I also originally considered 'versioning', but this whould require a persistet version number in every table, possibly not a good option for existing DB's or tables with very few columns and very much rows, because of the size overhead. you get an immediate exception or your changes block until the other guy commits (you get an exception) or rolls back (your transaction succeeds) As you may have seen from the diagram already, the first option is impossible with my approach due to the DB really locking on updates, it ever behaves as with the second option above. I think you could use a scheme like this at least with commit option A. Hmmm, I'm still unsure, if commit option A, multiple instances and locking play nicely together, need more time to consider different scenarios, I already said, I'm too slow thinking :-) Thanks and regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, Bill Burke: Why can't a transaction manage different resources and each of those resources use a different transaction-isolation level? What's wrong with that? There is nothing wrong with the idea IMHO. As I told earlier, some DB's (Informix) actually can do such isolation level switching inside a transaction. ANSI seems to not support that and so there might be DBs out, that follow ANSI and can't do it (or even worse, do an implicit commit). And the EJB specs seem to not like it, considering the least advanced common behaviour. No need for us, to do it better (and warn the user, that it is possibly not portable to other EJB servers, but who would wan't that anyway :-) (Ok, just kidding). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, David Jencks wrote: Yes, I was trying to point out that interbase/firebird has been doing this successfully for 15 years, we can have our container do it too, here's an algorithm you left out the most interesting: the algorithm! Please forward! Someone mentioned that there might be dbs using optimistic locking: interbase/firebird is one such. :-) As an aside, this versioning idea of Jim Starkey is the reason interbase/firebird exists. It allows a production database to generate meaningful reports: the report runs in a transaction that only sees the data present when the report started, yet production transactions can freely modify all the data in the db without affecting the report. This is the same with Oracle (one reason Oracle exists and still is one of the marked leaders :-). Note, that I'm not affiliated with Oracle in any way. Just used it the last 13 years (and other DBs as well, went back to Oracle most of the time). Oracle calls this 'read consistency' and at the lowest possible level only reads committed data and returns only data as of the time the query started, even when the read would need hours to complete and without hindering any other TX to update freely (including deleting ALL rows from the table). At that lowest level, this is not repeatable, the next same query then sees the data as of the new query start time, but there is a setting to do it repeatabe (which then USES locks, whereas the default behaviour is lock free). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi Marc Fleury wrote: precisely, I already fought with Vinay the many instances speedup fallacy it's a lie... if you don't break the pessimistic locking at the db then it is useless. so this puts more stress on me to implement it, as it is usefull already with multiple server instances. I still can't promise to start that before next weekend. |But maybe Bill is right, OL could be used with commit option A |and single bean instances too? I'm not really sure ... no I |don't think so, because then every TX is working on state |possibly modified by another TX and, even worse, with one did he propose that? I don't think so (could be) in any case I am rewriting the cache and one option would have to be a cache that upon looking up an instance if there is a transaction associated with it would clone (deep copy) the current instance so that each tx has a copy IN THE CACHE, this way the container flow is un-affected. If I understand you right, you would keep an unmodified original and give every TX a clone of that, right? As cloning, when the second TX comes in, would be too late, the cached instance could already been modified and then rolled back. Non TX threads get what, the original? Or better a clobber this when you don't know what you are doing clone handed out to every thread outside TX? Of course that supposes that we rely on the databases to synchronize the updates, for that we need to know that transaction isolation work properly across dbs. Not sure what you mean here, several DBs in same TX? Nevertheless I think the multiple instances cache would nicely fit together with the optimisting locking, wether it is naturally done by the DB or mimicked on top of pessimistic locking DBs (the latter having some pitfalls, see my earlier message with the diagram). Though I can't come up yet with a scenario where this will fail, why does the EJB spec 1.1 section 9.1.11 suggest a correspondence between commit option A and single bean instances? Does someone have a hint? btw this is why I am refactoring (rewriting really) the code in there. Well the first reason is to get rid of the busy wait bug, Really happy about that! but the nice by product is that you can use the right cache with the right database. I sent a small note yesterday on the transaction isolation... did you guys see it? yes, as you already might have seen from my other messages. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi who ever it was, said: I'm thinking of the isolation level as an immutable part of the transaction - partly because this is how the databases implement it (at least as far as JDBC goes). Sure, it would be useful to be able to specify different levels per bean, but given the apparent constraints that the databases are putting us under, implementing it against the database isn't feasable. Bill Burke answered: Just use a freakin' different connection pool for different beans and there is no freakin' database constraint. That would cause a problem with transactions and not XA compliant JDBC drivers, wouldn't it? The reason why JBoss pool pickes a connection from the pool based on the TX (reuses a connection with a TX when another connection is requested in the same TX) is, because current drivers often have a one to one correspondence between connection and transaction (as of comments in JBoss pool). As a result, when you wanted to switch isolation inside one TX the CMP code had to issue 'SET ISOLATION whatever' (or similar syntax for non Informix DBs), the JDBC call setTransactionIsolation() most probably can't be used, as it seems to behave ANSI like (does not allow switching inside a TX as of java.sql.Connection docs). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shall I check in code for the ROWID thingey??????
Hi Vinay, Has anyone bothered to go thru the ROWID based update code I'd sent out? I would really want to check it in but don't want to do so without a go ahead lest it affect any other portion of the server. If you want me to repost the diff code please let me know and I can do that. Oops, I'm sorry, I promised to do and didn't do that (see PS). Please resend, and PLEASE send us/me a unified diff with enough context lines by doing: prompt cd $JBOSS_HOME prompt cvs diff -u modified_file [modified_file ...] in ASCII instead of HTML to ease the job. Thanks, I'll review then, Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: my current employer seems to be out of money, so I had to do some DB teaching and I'm just about to accept a PERL/CGI job to earn my next lease instead of doing really good stuff. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption
Hi Gentlemen, Jay Walters wrote: Seems like an application requiring a CMP Persistence Manager and EJB container to execute SQL in a specific order might be asking a bit much to me... and Bill Burke replied: You'd have the same type of problems with BMP, wouldn't you? Sorry G's, I still can't see the point here. With BMP simply ejbCreate/Store/Remove is called at the appropriate places, especially ejbStore is called after every business method, isn't it? If not, would someone PLEASE point me to the code that does actually deferring the SQL, I just again spent 2 hours in org.jboss.ejb.** hunting for it. If I'm right, the BMP guy has all control over execution of SQL by simply doing the OO operations in some order (having referential integrity in the back of his head). Besides, is such a thing as RI useless/hindering in the OO world? I don't think so, even the pure OO guru respects integrity by i.e. not changing essential things before he knows for sure, that relatet changes can be done. (Else he would be no guru and should learn a session from the relational boys). And, last but not least, in the EJB context, heavily tied to relational store tier (by practical implementations and at least 'between the lines' of the EJB specs), it would be a shame to leave people without referential integrity, by not allowing them to have it on the store (Database) and not providing it in the next higher level by declaration (the entiy bean level). Again, when the BMP guys have full control, why should EJB Server/ Container developers want to leave the CMP guys in the wet? Note, that I'm not against the push() thing just published on top the EJB 2 requirement to 'store before find', but I consider it 'Janus' headed: one side parfumed like a feature, the other one stinking like a workaround. Back to my past suggestion of respecting the ORDER of OO calls: A simple, but imperformant, solution would be to execute storeEntity() after each business method and in create/remove. I believe now, that the real flaw is caused by the fact, that the EJB specs consider every field/attribute of a bean to be equal in semantics to each other, with the exception of the Primary Key field(s). But they didn't learn their lession really from the relational poor mens! They COMPLETELY ignore the very different semantics of FOREIGN KEYS (place holders for Associations of all sorts). This discussion threads problem never comes up, when changing simple attributes/fiels, that ain't related to anything, but the primary key of the bean instance (1:1, normally). But it shows up, when attributes, that represent associations, are modified. JAWS/JBoss needs to know about the SEMANTICS of fields/columns and then can come up with performant/'intelligent' handling: If deferral to commit time is suggested, then QUEUING up all store requests related to one TX (including create(), remove() and store() and possibly find() for DIFFERENT instances/beans) will help: if ANY store request affects data with FOREIGN KEY / Association semantics, the queue must be processed physically to the underlying store, until empty, before executing the call with association semantics (only as a first attempt, we will be better in a few days!). Thus several changes to simple attributes of the same bean instance intermixed with creation/removal of other bean instances would nicely be accumulated to only one store() operation (and several unrelated create/delete_stores). But a change of a FOREIGN KEY / Association field would trigger the queue processing before doing the change to the assoc field, resolving this threads sort of problem. Further requests to simple attributes then again accumulate to the queue. Makes sense, doesn't it? Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
Hi, How about using the Java Coding Standard by Sun? yes, most people have seen that, it's easy to get by looking at http://java.sun.com/docs/codeconv/, many people already follow it. other open source projects ... have been mostly 4 (spaces). yes, 4 columns indent clearly, everything hanging after column 128 should be considered bad coding style. Most editors CAN do spaces, some can't cope with TAB. Others mentioned formatting tools already (jindent i.e., I've 'jip' [Java Is Pretty] here, waiting to be used), so extreme guys can have what they want and format back before checking in. not 2 cents worth, but to have been said Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
Hi Vinay, hi all, Vinay: This basically means that even within the same transaction the rowid will be updated if the client attempts to do an update [or delete]. Do we now need to check for rowid being null and falling back to the primary key if it is not? I had written some code for this and was surprised that it was never being called. Georg: Which commit option was set for your entity bean? If it were B or C, it's clear, that the instance is loaded within a TX, but with A and with B (outside TX) the load should NOT happen, thus the check for a null rowidValue would be better. Vinay: Nope! That is what I thought as well. The bean *is* being loaded even with commit options A and B, for the same operation with the transactions settings remaining the same. If you are right, I would consider it a bug, rendering commit option A and B useless, which promise bean caching. And I checked against binary JBoss 2.2.1, BMP, commit option A and Requires: DEFINITELY the sequence of calls when creating an Entity bean is TX 1 | - setEntityContext() | - ejbCreate() | - ejbPostCreate() TX 2 | - getter method | - setter method | - ejbStore() As you see, there is NO ejbLoad() between ejbPostCreate() and the business methods, in fact ejbLoad() on this bean is NEVER called, except after passivation/reactivation, as expected. This same behaviour should be seen also with CMP! If this behaviour has changed with the current CVS JBoss there must be some problem been introduced. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: Sorry, I just can't test with the CVS version. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
Hi all, trying to sort that out. David Esposito showed us a perfectly OK sequence of modifications to some Entity beans within one TX. He reported problems with JBoss accessing the DB while persisting, because of changed order of modifications, creates/deletes seem to be done before updates, regardless of the OO sequence of calls. This comes surprising to me, anybody around to tell, if and why this is the case? Is it only with CMP somehow, I can't see this with BMP? Everything would be OK, if JBoss did sync in the very same order to the DB as the OO code requested it. Regardless of doing the ejbStore() at the end of TX or after calling a business method: just do it in the same order. Even intermixed stores would be no problem, when done IN THE SAME ORDER (this respecting the recent change to finders doing a store before finding, as requested by EJB spec 2.0). Please remember: a TX on a DB actually SEES the changes it has done in it, although no other TX can see that until commit. Now to the RI (referential integrity) thing: A DB RI setting of ON DELETE CASCADE must be considered as beeing another application modifying the DB concurrently to JBoss, so the commit option HAS to be set to at least B, and the code in the beans then MUST be prepared to accept concurrent changes by some app outside JBoss and handle that gracefully. I.e. in Davids case he must be prepared to expect cc.setRecord() to fail IF HE HAD called mca.remove() HIMSELF BEFORE or IF HE HADN'T FETCHED mca BEFORE modification to cc ... but his code still is OK. A DB RI setting of checking validity of Foreign Keys should not be problematic even with commit option A (note off topic: depending on your mapping of inheritance to your DB this COULD be a problem). Besides, not changing the order of access to the DB leaves control of LOCKING to the bean implementor, thus DEADLOCK avoidance is to him ... but he hasn't the same possibilities, as the typical relational DB developer has: the RDB developer always can ROLLBACK when he discovers, that some required lock can't be aquired (SELECT ... FOR UPDATE NOWAIT for Oracle, similar for other RDMS's). The EJB developer is lost here, the spec simply drops him 'serialized' possibly waiting for a bean held by his competitor which itself is blocked cyclic. The only way to handle deadlock is 'ordered access', which in practice seems to be impossible, especially respecting the above requested access to the DB in the same order, as the OO code needs/expects it. There is a hint in the EJB specs 1.1, that the container might reorder access to the DB to actually try ORDERED access to the DB (i.e. in increasing PK order) to avoid deadlock. But I just now can't come up with a pattern, that is safe and avoids deadlock, any taker? Conclusion: today let JBoss respect the OO order of access to beans and do it the same way to the DB. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Should storeEntity be called after every invocation?
Hi Bill, all, Bill Burke wrote: All, We have the following (bad?) assumption in our application code: begin transaction Bean b = findByPrimaryKey(...) System.out.println(flag = + b.getFlag()); // prints flag = 1 b.setFlag(0) Enumeration = findByAllBeansWithFlagEqualToOne() // where flag = '1' // We assume Bean b is not in the Enumeration, but it is. end transaction My question to you guys is, Should storeEntity be called after every Entity method invocation? Right now, a database update only happens when the Entity is commited. What does the spec say on this? I can't find anything at the moment. As of my experience with i.e. Oracle your assumption is ok, changes done inside an open transaction should be seen by queries done in the very same transaction, although not committed. (And I think, this is ANSI/XOpen too). Searching the EJB specs (1.1) I didn't find any similar statement (have spent an hour and hit over 50 more/less related places). But synch to the DB seems to be VERY expensive just to find back what's already in the cache, and then possibly to be rolled back, isn't it? EJB 1.1 seems to ignore this issue at all, the most interesting places are quoted ´below. From 9.4.2, adapted to your scenario, I assume, that the spec sucks: you would evenly expect to see freshly created beans in your TX, but that section allows deferring the insert 'to the end of the transaction'. A better solution to this seems to have finders work on the EJB server instead of the persistence store, respecting transactions? But the spec doesn't allow it. (?) Hmmm, am I babbling rubbish? Sorry to be too tired to continue. best regards as usual Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 Quotes from the spec: 9.1.7 | The container invokes the ejbStore method at the end of a | transaction, and may also invoke it at other times when the | instance is in the ready state. (For example the container may | invoke ejbStore when passivating an instance in the middle of a | transaction, or when transferring the instance's state to another | instance to support distributed transactions in a multi-process | server.) 9.1.4, somewhere in the middle | The purpose of the ejbLoad and ejbStore methods is to synchronize | the state of the instance with the state of the entity in the | underlying data source - the container can invoke these methods | whenever it determines a need to synchronize the instance's | state. 9.1.6, in the middle | The container must invoke this method on the instance whenever it | becomes necessary for the instance to synchronize its state in | the database with the state of the instance's fields. This | synchronization always happens at the end of a transaction. | However, the container may also invoke this method when it | passivates the instance in the middle of a transaction, or when | it needs to transfer the most recent state of the entity object | to another instance for the same entity object in the same | transaction (see Subsection 11.7). 9.4.2, near end | The container may create the representation of the entity in the | database immediately after ejbCreate(...) returns, or it can | defer it to a later time (for example to the time after the | matching ejbPostCreate(...) has been called, or to the end of the | transaction). ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Should CacheKey copy its id on creation?
Hi ALL, 1- TURN OFF HTML! [tuned no of '!' -re-] Yeah, sorry, Outlook seems to do this sometimes without warning Yes, but see Outlooks 'Format -- Plain Text' menu. May I add (politely) the requirement to cut off irrelevant tails of previous conversations, and especially repeated footers pointing us again and again and again and again and again and again and even again to SourceForge. Thanks Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] FW: Busy wait on one thread
Hi Bill, I've rewritten EntityInstanceInterceptor a little(see my race condition fix email please) and put it some code so that LOCKING-WAITING isn't printed a zillion times. I also added a Thread.yield() before continue; in the lock-do-while-loop. nice to hear that. I've also started looking into ditching the do..while loop in favor of wait/notify. It's much more complicated than I originally anticipated, but I'm making progress. IMHO, the whole locking business should be ditched when you have commit-option-C. Let the database to the synching for you with the select-for-update feature(CMP) or make the BMP developers handle the locking. I assume including the activation of MULTIPLE bean instances? 9.1.11 Fig 24. And then, don't forget about optimistic locking behaviour, which would help a lot when many clients mostly access beans concurrently for read only purpose. Optimistic locking (sort of) can be mimicked with relational DBs that don't have it built in by using a where clause in update/delete that not only specifies the PK values (or the rowid) but also all changed fields with their OLD values. A CMP/JAWS impl would require the old state to be saved and generating dynamic WHERE SQL clauses based on the diff. BMP developers have to do it similar by hand. Sample for readers unfamiliar with SQL (nobody here): bean fields: pk, name, address; address changed, old state known generated SQL: update bean setaddress = new value where pk = pk value ANDaddress = old value This way the SQL can only update 1 row, when nobody has concurrently modified the changed fields, if statement.executeUpdate() returns 0 it must be interpreted as a concurrent modification coming too late and the TX must be rolled back. Another variant could use a time stamp field similarly. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP fields XML Serialization
Hi Vincent, I find it more spec compliant to have a String cmp field containing my XML respresentation. a getter method that do XML--Object a setter method that do Object--XML Or even better to do the conversions in ejbLoad() and ejbStore() to be more performant with cached beans. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unspecified transaction context always rollback - bug?
Hi Gerald, While following the recent LOCKING-WAITING threads I've been experimenting/tuning my beans for concurrency by turning reentrant on and setting TX_SUPPORTS. Great improvement! ... Tell me about it... Friday is my last day of work and I've got to hand this project over to a couple beginner Java programmers, yet I've spent all afternoon tuning and looking through the jboss source and there's plenty more coding to do. So hopefully this message doesn't come too late? I had implemented isModified shortly after realizing that every get was executing ejbStore - while keeping jboss moderately busy, postgresql would eat 30% cpu executing updates! Ok, I see. I was wrong about the getters (only the setters cause isModified to return true...), however the finders still cause rolledback selects (no real problem, just silly looking). No real problem sounds good. From your original mail: This may arguably be a bug because the EJB specification (11.6.3) doesn't define what the container should do, but after reading it, I get the feeling that it shouldn't rollback. I agree mostly, but then 11.6.3 is really annoyingly unspecific, allows the container to do almost anything (there is a the list is not inclusive of all possible strategies sentence) and leaves the bean developer in the wet (the enterprise bean must be written conservatively not to rely on any particular Container behavior.) It looks as though jboss implemented the first possible strategy: * The Container may execute the method and access the underlying resource managers without a transaction context. I had a look at TxInterceptorCMT.java and you seem to be right, the business/home method is invoked without any transaction context (when requested by Supports, Never and NotSupported) and there seems to be no attempt to set autocommit to true ... and as there is no active transaction at all JBoss CAN'T do a rollback after method invocation. So the rollback you see in your debug log must come from somewhere else, might be from your JDBC driver? Potentially elsewhere in the app, a similar taglib could execute some finders, then invoke incrementVisits without a transaction, which would cause isModified to return true, then ejbStore would execute the update, but jboss would rollback (and the bean instance would still have the new values that weren't commited to the database). As I just told, I don't think JBoss is rolling back, it would be too stupid to do that and leave the out of sync instance in memory, hey, there may be some subtile errors in JBoss still, but no sillyness. But I agree, it might be best to set autocommit to true, would avoid problems with drivers not knowing how to handle statements without a TX and should be fairly easy to be implemented (at least for the gurus here on the list). As I said before you should NEVER attempt to write a bean outside a TX, as there is no guarantee at all, that any EJB server (including JBoss) will actually call ejbStore() (see spec 9.1.7.1). 9.1.7.1 suggests DB access in the business methods instead, this should work, if autocommit were on and the bean were not reentrant. But I would suggest another schema: - use commit option B - have your getters and finders Supports - have your create/remove and setters Required - mark the bean as reentrant - access your Entity beans through a Session bean facade to have declarative Transaction attributes (and business logic); alternatively use UserTransaction in your clients (does NOT work with JBoss 2.2.2 yet, but only with the CVS version) - read without TX for pure display purposes, where reliability isn't that important, you gain advantage from JBoss caching the beans state with option B and without TX - write within a TX, option B forces ejbLoad() before the business method executes and you have reliable data to modify; if your modification depends on the actual state you are free to first read the state then calc and write the state all within one and the same TX from the session bean my very best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Dear Vinay, Have started looking at the code again, Do we want to specifically say 'oracle-tuned-updates'. What if actually proves useful for some other database - can't we just call it just 'rowid-column' and use the presence or absence of the tag to use rowid based updates? What about 'stable-rowid-column' and a good comment and documentation? regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Option D in SynchronizationInterceptor
Hi again, K.V. Vinay Menon wrote: Why is the validContexts in the new option D enabled EntitySynchronizationInterceptor *NOT* synchrnoized. Will you really have a thread safe implementation in that case? I'd sent out an implementation of the soft ball cache refresh option sometime back [which I never got time to check in!!] and that was after finally persuading Marc that we had to synchronise the hashset. As far as I remember Marc was never really conscious of synchronization in this case, worst case that can happen in a race between looking for a ctx and adding to/clearing the hashset would be the lookup failing, thus synchronizing an instance earlier than neccessary. On the other hand the docs explicitely require synchronization on HashSet, I don't know what happens in a race between adding and clearing the set, maybe some internal structure will break. Though I could look at the implementation, I believe it's better to do NOT, but stick with the docs, as the implementation might change without notice! Also, a. the hashset is unique anyway why check for presence! Don't exactly know what you mean, but the HashSet is only used for commit option D and the class handles A,B,C also. b. there will be only one ctx per bean [correct me if i am wrong]. Do you mean one ctx per bean CLASS? No, the ctx has i.e. the transaction and the security settings attached, so there is one context per bean INSTANCE, isn't it? Also then we'd planned to have it as a separate class that could be fit into the inteceptor stack if required. Was surprised too, but then the additional code is really only a few lines and the semantics seem far more clear to me with this solution (i.e. the switch (commitOption) in afterCompletion()). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Hi Dan and Vinay, The reason I was suggesting an oracle specific option name was because I really think that we need to use the Oracle specific syntax to return the rowid value on inserts. Oops, I forgot about that. But Vinay is right, a stable ROWID might be present in several other databases already or in future. The 'insert ... select into' syntax today seems to be Oracle 8 specific (remember, Oracle 7 does not have it), but could make it into some standard? At least one and the other are not too closely related, this syntax especially can get back whatever you want from the just inserted row, not only the ROWID, but even some sequence value, some expression list to be more general. And other DB's having a stable ROWID ain't lost, as Vinay's code now falls back to the PK when a ROWID value isn't available. So I suggest 'stable-rowid-column' (including good docs) and a new tag 'insert-select-list' specifying a comma separated list of expressions to select from the inserted row and an appropriate number of placeholders for the result after a semicolon. (Or better, feel free to define the syntax, you got the idea). bye, my very best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Dear Bill and Dan, I'd really like to go in and fix this problem, but I really need another set of eyeballs to make sure I'm doing things right. Danch, can you volunteer to help? Also, while I'm in this code, maybe I should consider adding the Missing wait/notify and remove that buggy do..while loop as well. I can certainly review. I won't have much time for investigation until this evening, and then my wife may have other plans for my time. I would be really happy, if you both could manage to correct the wait/notify issue while on that code and fixing the race condition. Besides, I just answered a message, where someone seemed to have a deadlock, that remained unresolved, though server log messages told, that the transactions timed out (3 TX reported). The guy had to restart JBoss, the log was filled up with LOCKING-WAITING (TX). best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: I don't think, I can really help, but I'll follow this thread maybe at least I can document something. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hi Vinay,
see below
In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to
indicate whether the bean can be optimized for read only
operation. In the EntityInstanceInterceptor, where the loop
actually wait for the lock I've added a condition
isReadOptimized = metadata.isReadOptimized();
if(!isReadOptimized)
{
...
...
go about as usual trying to aquire lock etc
}
mi.setEnterpriseContext(ctx);
return getNext().invoke(mi);
and in the finally clause
if (ctx != null (!isReadOptimized))
{
//business as usual code
}
What is good is that I no longer have my response times creeping
up under sustained loads. Does this look alright? Does anyone
anticipate any other problems due to this. Would really
appreciate if folks who really have the 'bigger picture' can let
me know.
Might be better you provide a context diff to us, so we more
exactly can see what you plan to do (change code, do
cvs diff -u EntityInstanceInterceptor.java).
As far as I understand, you skip the whole
do { ... } while (ctx == null); loop? So you end up with a null
EnterpriseContext, not a good idea IMHO, because i.e. security
and transactional settings (amoung other important things) are
attached to it, most likely invoked other interceptors rely on
the ctx set?!
Where does your isReadOptimized come from, JAWS? If so, the BMP
developers are left alone.
I still would insist on the correction of the missing wait/notify
issue, as I still believe that the extremly bad response times
under load are more caused by several threads executing tight
loops consuming most of the cpu time instead of simply waiting
and let the cpu to JBoss doing real work!
I'm NOT a multithreading expert though. My first thought was to
simply insert a wait() directly after the two
Logger.debug(LOCKING-WAITING ...); calls and a notifyAll()
after the ctx.unlock() in the finally clause, but I've 2 problems
with this approach:
1. there is a mutex.aquire()/mutex.release() pair; when I simply
would wait inbetween, I think no other thread can enter the code
thus rendering EntityInstanceInterceptor dead, when one thread is
waiting, on the other hand, I can't simply release the mutex
there, it's a critical section. A solution would be to have a
wait directly before the } while (ctx == null); if ctx == 0 as of
this (hand made) context diff:
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
+ if (ctx == null) {
+ // let the thread that has the lock proceed
+ // at same time let's detect possible deadlock
+ long start = System.getCurrentTimeMillis();
+ try {
+ wait(DEADLOCKTIMEOUT + 1000);
+ }
+ catch (InterruptedException ignored) {}
+ finally {
+ if (System.getCurrentTimeMillis() - start
+DEADLOCKTIMEOUT)
+ {
+ throw new EJBException(
+ possible deadlock detected);
+ }
+ }
+ }
} while (ctx == null);
...
...
else
{
// Yeah, do nothing
}
+ notifyAll();
}
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
2. the notifyAll() above better should not awake any thread in
JBoss, but better only the threads that wait above, hmmm, isn't
this implicit? Do we need thread groups? It would be
best/required that the Interceptor only waits, when the same bean
instance is to be entered concurrently (this should be so
already) and that only exactly the threads, that wait on the same
instance should wake up. Please remember, I'm unexperienced with
multithreding and JBoss, just lost on this.
___ ___
| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Dear Vinay, No. Not really. Its is just that the new Oracle release clearly state advantages of using rowids for updates and it is very attractive to have that kind of a facility for updates and deletes on huge tables [we do have quite a few tables that are in excess of 5-6 million records]. The idea is to have the option at hand so that it can be used as and when required [which is going to be quite a lot]. Agreed. Issues like the client accessing the bean immediately after creation are things applications take care of by design - proper transactions and a decent session facade that ensures that screw ups don't happen. would be better your code would check for a null or empty rowIDValue and then fall back to using the PK field(s), so it would be safe even after create! (Tried to find that in your source on the list, couldn't find that check, but may me I'm too tired yet). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unspecified transaction context always rollback - bug?
Hello Gerald, While following the recent LOCKING-WAITING threads I've been experimenting/tuning my beans for concurrency by turning reentrant on and setting TX_SUPPORTS. Great improvement! Ah, at least one person giving it a try, thanks. I should have done this on my own, but I'm just too busy reading and understanding JBoss code (and really, I have more than enough work to do USING JBoss and not trying to understand it in depth, my boss is very unhappy with me the last days). However sql statements always rollback after the bean gets invoked (creaters, finders, getters/setters anything) without a transaction context. Oops, that again comes unexpected for finders and getters. Do you have isModified() implemented in your beans? If not, would you give it another try, implement isModified() and only access your beans via finders and getters? Does the rollback show up then? If so, would you please send stack traces to this list (or to me)? My suggestion (no TX + reentrant) was really ONLY for pure readonly access to beans, NEVER attempt to create, update or delete a bean without a TX! Thanks Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Caching - Locking - Server Dies!
Hi Vinay, hi all, Oops, I'm verbose again, (not really) sorry. I have tried both options. Started without a container transaction defined. In which case it kept throwing LOCKING-WAITING transactions [from the EntityInstanceInterceptor] which says that JBoss is creating a transaction automatically. Yes, because of the default Required TX attribute. Next I changed the ejb-jar to specify the container transaction as REQUIRESNEW and as expected it did create a new transaction and hence showed the same messages. Yeah. Finally, changed the container transaction to SUPPORTS when it stopped locking for the TRANSACTION and started locking waiting for the CTX [Context] in the else clause of the EntityInstanceInterceptor's invoke method. So there you go. Oops, I didn't expect that! Not that I really have a deep understanding of the code, but the problem seems not to be with the locking of the context, but with your beans not beeing marked as reentrant, thus only one client can access a bean at any given time. The code there does not distinguish between a method executing in the right transaction and a method executing without a transaction at all. I just can't remember if the EJB specs are clear about non reentrant beans accessed outside a transaction (have to read that thing even once more :-(), but the implemented behaviour is on the safe side. Not beeing 'reentrant' allows the bean provider to write simple code without synchronizing and all the complicated issues, that arise when you must consider concurrent access (and synchronizing etc. is forbidden anyway in EJBs). See spec 1.1 9.1.12. Only when you have 'callback' in mind, you should allow reentrant beans. In your case, I'm pretty sure, that the conflict is NOT caused by callbacks, but by several clients attempting to concurrently access your beans. Within a transaction this clearly must be blocked (or, as the specs require, 'solved' with a RemoteException). But in your case, only reading the beans outside a TX, where the gotten state must be considered invalid, wrong, old, outdated anyway, it should be no problem at all to allow concurrent access. So, to continue your tests, declare your beans as 'reentrant'! What's not nice with this workaround is, that a reentrant bean might get accessed inside one and the same transaction from different clients (in the rare case, where a superclient starts a transaction, then spawns new threads (inheriting the TX) for different activities, do you know other scenarios?). So it might be better, to change the code to sort out access outside a TX allowing concurrency even when the bean is not reentrant?? And, besides, the code suffers from the same problems as I told you in my last mail to this thread: not waiting and thus going into a tight loop with tons of messages and eating up CPU time; maybe, it would be better to throw the RemoteException the spec asks for? Why is it locking for readonly bean? Why does it need to do it? For the transactional case I told you already; for nontransactional access I propose ignoring the reentrant flag (only if the spec does not explicitely disallow it or someone can point out the danger with it). The effects are only marginal and hardly detectable at low loads. It is more pronounced at higher loads and as the table size increase it goes into a real amplifying loop where the beans wait and take longer to return and that in turn cause the lock to be longer and so on. Would be 'solved' by an Exception and should be considerably better, when the server actually would wait instead of going into the tight loop. Strange that the method does not check for read-only attribute either? Why is that? As of the spec there is no 'readonly' method, name it: the spec sucks? best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem running jbosstest
Hi Ole, I could easily commit that change, but: Am I the only one who has seen this problem? Might be, you are the only one testing? :-) regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] current CVS build hangs on startuo/shutdown
Hi all, attempting to test a modification I built the current CVS JBoss (without changing anything and without build problems [except 6 uses of a deprecated api]), tried to start it up and experience a hang when JBossMQ starts. For the last few lines of the console output see below, the full server.log is attached. JBoss seems to hang forever (at least longer than half an hour). When attempting to shut it down with Ctrl-C it hangs again, this time when stopping the UserTransaction manager. Has someone a hint, what I can do to get it running? - startup console log start/tail - | JBOSS_CLASSPATH=;run.jar;../lib/crimson.jar | jboss.home = E:\java\jboss-cvs | Using JAAS LoginConfig: file:/E:/java/jboss-cvs/conf/default/auth.conf | Using configuration default | [root] Started Log4jService, config=file:/E:/java/jboss-cvs/conf/default/log4j.properties | [Info] Java version: 1.3.0,Sun Microsystems Inc. | [Info] Java VM: Java HotSpot(TM) Client VM 1.3.0-C,Sun Microsystems Inc. | [Info] System: Windows 2000 5.0,x86 | | [JDBC provider] Starting | [JDBC provider] Started | [Hypersonic] Starting | [Hypersonic] Database started | [Hypersonic] Started | [InstantDB] Starting | [InstantDB] XA Connection pool InstantDB bound to java:/InstantDB | [Default] Enhydra InstantDB - Version 3.26 | [Default] | [Default] The Initial [Copyright message CUT] | [Default] Server 1.4 is running | [Default] Press [Ctrl]+[C] to abort | [InstantDB] Started | [DefaultDS] Starting | [DefaultDS] XA Connection pool DefaultDS bound to java:/DefaultDS | [DefaultDS] Started | [Container factory] Starting | [Container factory] Started | [JBossMQ] Starting - shutdown console log tail - | [Default] Shutting down | [Service Control] Stopping 27 MBeans | [Container factory] Stopping | [Container factory] Stopped | [DefaultDS] Stopping | [DefaultDS] XA Connection pool DefaultDS removed from JNDI | [DefaultDS] XA Connection pool DefaultDS shut down | [DefaultDS] Stopped | [InstantDB] Stopping | [InstantDB] XA Connection pool InstantDB removed from JNDI | [Default] Database instantdb is shutting down... | [Default] Database instantdb shutdown complete. | [InstantDB] XA Connection pool InstantDB shut down | [InstantDB] Stopped | [Hypersonic] Stopping | [Hypersonic] Database closed clean | [Hypersonic] Stopped | [JDBC provider] Stopping | [JDBC provider] Stopped | [JAAS Security Manager] Stopping | [JAAS Security Manager] Stopped | [Client UserTransaction manager] Stopping | . delay of 1 minute or so, then . | [Default] The database is shutdown | [Default] The database is shutdown Thanks Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 server.log
Re: [JBoss-dev] minerva source
Hi Doug, Where can I find the org.opentools.minerva.jdbc.xa.wrapper.XADataSource.java file? Searching old (2.2.1 :-) JBoss jars I only found org.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl.class the source for it now is under org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl.java and implements javax.sql.XADataSource, I'm pretty sure, this is what you want to look at. have a nice weekend Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntitySynchronizationInterceptor.java
Hi Marc, hi all, The idea is that option A/B/C in the spec are *brain dead* it either always refreshes or never refreshes... here we offer a simple way to specify a refresh time. A feature I really would like to have is dynamic switching of container commit options. This would enable good caching via A most of the time, then switching to B/C to allow legacy apps to do mass updates/deletes for some time without breaking JBoss, finally switching back to A when the other app is done. Do you see a chance to have that? Thanks for your time Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: I know, I just should do that in an Open Source project. If I get some hints, I might volunteer. May be, via the JMX management interface it could be done already? now I will have to change the training Is this training available? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss pool (former Minerva) transaction bug?
Hi, Tyrex upon getting successful commits from the XAResources, being in 2pc sets heuristic to COMMIT and asks the XAResources to forget() the transaction. I don't understand what JTA is talking about with heuristic this and that. It seems like a mechanism for dealing with strange situations or something. As far as I know (from Oracle 2PC) the heuristic stuff is needed to handle errors inbetween the 2 phases of commit, i.e. when 3 resources are to be committed, the TM asks them to do the 1st phase and waits for the outcome; assume the request comes through to all three (distributed) resources, all of them can commit after a while, but one of them can't report back success or failure because of a broken network, that lasts for a long time. The TM can't finalize the transaction, the resources remain locked. With help of the heuristics administrators then are able to finalize 'by hand'. Depending on the heuristics, if any indicates rollback, all resources must roll back even when they were able to commit locally in the 1st phase. Only when all heuristics indicate commit, the resources may simply forget the pending transaction, thus giving up locks, freeing rollback buffers and finalizing the already done local commit. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS modules
Hi developers, would anybody care to update the CVS modules file, to support 'cvs checkout -c/-s', it currently only has 'ejboss' in it (which is obsolete and old, isn't it)? This might help people avoid asking questions about where to find source (and more or less angry answers a la RTFMailinglist Archive) in jboss-user. And the modules list at http://www.jboss.org/business/cvs.html doesn't seem to be up to date either (i.e. jbosspool and manual are missing). Thanks Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] advconfig.xml
Dear developers, a week ago I tried to contribute some lines of documentation, since then I got no response at all, neither a flat denial, nor corrections nor an OK, so I assume the message got lost/overlooked. May I again ask someone to look over the text and if it's OK to check it in? Thanks Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 - Original Message - From: Georg Rehfeld [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 19, 2001 12:34 AM Subject: Re: [JBoss-dev] CVS update: manual/src/docs advconfig.xml Hi all, + para + ![CDATA[commit-option must be A, B, C, D (after 2.2.1). ]]/para + paraOption A: The Container caches the bean between transactions. This options assumes that the bean/container is the only one accessing this data. Therefore, the container will never synchronize the bean with the persistence storage, ejbStore/ejbLoad never get called./para +paraOption B: The Container caches the been between transactions. However, unlike option A the container does not ensure exclusive access to the persitence storage. Therefore, the container will synchronize at the beginning of each transaction./para +paraOption C: The Contianer does not cache bean instances and instances are synchronized on every transaction./para +paraOption D: This is a JBoss specific feature available in versions newer than the 2.2.1 release. It enables a lazy write schema, where synchronization does happen but not upon every transaction. + /para I think, this documentation is not fully correct and misleading the reader. It should read similar to the following: - snip - para ![CDATA[commit-option must be A, B, C, D (after 2.2.1). ]]/para para Option A: The container caches the beans state between transactions. This options assumes that the bean/container is the only one accessing the persistent data. Therefore the container synchronizes the memory state from the persistent storage only (via ejbLoad) when absolutely neccessary (when the state isn't cached yet), that is before the first business method executes on a found bean or after the bean is passivated and reactivated to serve another business method. This behaviour is regardless of wether the business method executes inside or outside a transaction./para para Option B: The container caches the bean between transactions. However, unlike option A the container does not have exclusive access to the persistent storage. Therefore, the container will synchronize the memory state (via ejbLoad) at the beginning of each transaction. Thus business methods executing in a transaction context don't see much benefit from the container caching the bean, whereas business methods executing outside a transaction context (transaction attributes Never, NotSupported or Supports) access the cached (and invalid) state of the bean./para para Option C: The container does not cache bean instances and instances memory state is synchronized on every transaction start (via ejbLoad). For business methods executing outside a transaction the synchronization is done too, but as the ejbLoad executes in the same transaction context as the triggering business method, the state must still be considered invalid and might already have changed in the persistent storage when the business method executes./para para Option D: This is a JBoss specific feature available in versions newer than the 2.2.1 release. It enables a lazy read schema, where the beans state is cached between transactions as with option A, but resynchronized from the persistent storage from time to time (via ejbLoad). The default time between resynchronizations is 5 seconds but you may configure the time (in seconds) with ![CDATA[optiond-refresh-rate30/optiond-refresh-rate]]./para para With all four commit options the container must synchronize the bean instances cached state with the persistent storage (via ejbStore) at the end of each transaction (just before a commit is done) to be sure the whole transactions state is consistently persistet. As of the EJB specification there is no safe way for the container to decide, if the beans state actually has changed since transaction start, so ejbStore is called, even when all access to the beans business methods was read only. Note, however, that JBoss supports an optional method public boolean isModified() in the beans implementation. If this method returns false, the call to ejbStore is skipped at commit time./para para A final note to executing business methods outside of a transaction context: when reading the beans state you always must consider the result as invalid and usable for rough display purposes
Re: [JBoss-dev] advconfig.xml
Dear Per, dear Tobias, Per wrote: To me newer than the 2.2.1 release is ambiguous. I agree, if or when the first release that has commit option D is known it should be expicitely named. Tobias (alias gropi?) wrote: Log: Clarifications for the commit-option Jetzt ist's ins cvs comitted. Thanks for proof reading and adding it to the docs. best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: manual/src/docs advconfig.xml
(re)read and write the bean within one and the same transaction context. /para - snap - Migth someone with more code insight please validate that text? Please note also, that english isn't my native language. If this text is accepted, would somebody (gropi?) consider to check it in? Besides, in the current CVS main branch I couldn't find the support for the D_COMMIT_OPTION, neither in ConfigurationMetaData.java nor the new SoftBallInterceptor. Best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jar hierarchy
Hi all, Peter Fagerlund asked: In what jar file is org.jboss.jdbc located - I need to do a test run with Toby Allsopp answered: jboss.jar, I think. yes, there it is. Please don't call me a Spammer, but may I suggest a shareware tool for the W98/NT/W2K users which helps me a lot in my daily work: 'Windows Commander' (http://www.ghisler.com/). The reason I name it here is: it can easily made to search all sorts of archives including Java JARs for files and contents of files. Archive and ftp handling is seemlessy integrated and the usability is tuned to the last keystroke, it's a really superb replacement against the explorer :-) If anybody is interested how to set up WC to search Java JAR archives, I can explain. Bye Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
