dirkv 02/02/09 08:53:48
Modified: src/stores/slidestore/j2ee J2EEDescriptorsStore.java
Log:
add FIXME: Concurrent access to the J2EE store
Revision Changes Path
1.3 +51 -7
jakarta-slide/src/stores/slidestore/j2ee/J2EEDescriptorsStore.java
Index: J2EEDescriptorsStore.java
===================================================================
RCS file:
/home/cvs/jakarta-slide/src/stores/slidestore/j2ee/J2EEDescriptorsStore.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- J2EEDescriptorsStore.java 5 Feb 2002 04:07:12 -0000 1.2
+++ J2EEDescriptorsStore.java 9 Feb 2002 16:53:48 -0000 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-slide/src/stores/slidestore/j2ee/J2EEDescriptorsStore.java,v 1.2
2002/02/05 04:07:12 msmith Exp $
- * $Revision: 1.2 $
- * $Date: 2002/02/05 04:07:12 $
+ * $Header:
/home/cvs/jakarta-slide/src/stores/slidestore/j2ee/J2EEDescriptorsStore.java,v 1.3
2002/02/09 16:53:48 dirkv Exp $
+ * $Revision: 1.3 $
+ * $Date: 2002/02/09 16:53:48 $
*
* ====================================================================
*
@@ -88,18 +88,62 @@
/**
* JDBC 1.0 and 2.0 compliant store implementation.
- *
+ *
+ * Alpha version (for development only)
+ *
* @author <a href="mailto:[EMAIL PROTECTED]">Remy Maucherat</a>
* @author Ashok Kumar
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class J2EEDescriptorsStore
extends AbstractService
implements LockStore, NodeStore, RevisionDescriptorsStore,
RevisionDescriptorStore, SecurityStore {
-
-
+
+// FIXME: Concurrent access to the J2EE store
+// ===========================================
+// The following is a summary what has to be done to complete the J2EE store
+// This applies to both J2EEDescriptorsStore and J2EEContentStore
+//
+// http://marc.theaimsgroup.com/?l=slide-dev&m=101093479323729&w=2
+// http://marc.theaimsgroup.com/?l=slide-dev&m=101095180715067&w=2
+// http://marc.theaimsgroup.com/?l=slide-dev&m=101304906406795&w=2
+// http://marc.theaimsgroup.com/?l=slide-dev&m=101304998408694&w=2
+//
+// (Dirk)
+// I think something is missing in the store implementation and that's why
+// you also get those wrong content lengths that you reported in your mail
+// "Problem with GET and content Length". A second user sees the new
+// content length before it is committed.
+//
+// In the current implementation, there is only one Connection object and
+// that connection object is used in all threads (for all concurrect
+// requests/transactions). I always had the impression that you had to get
+// a separate connection for each concurrent transaction.
+//
+// (Remy)
+// Your analysis is accurate.
+//
+// More specifically, we should have a hashtable of active connections keyed by
+// the global transaction id (add them to the hash when doing the first start,
+// and remove them when committing or rolling back the transaction).
+// That's how I was planning to implement it originally, anyway.
+//
+// Here, as you said, the connection object gets used simultaneously in
+// different transactions, which may indeed cause the problems with dirty reads
+// (of course, it's rather hard to predict).
+//
+// (Remy)
+// I think you need to associate 1 connection <-> 1 global transaction ID, and
+// put back the connection in the pool at the end. That's also what Dirk
+// suggested, if I remember well.
+// IMO, you also can also fully rely on the DataSource TX isolation (or at
+// least allow it as an option), and always accept enlistment in a transaction
+// (the DB will then handle the rest, which could be finer grained, so it
+// should end up being faster).
+
+
// -------------------------------------------------------------- Constants
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>