I was diving in Derby source last night, trying to find transaction related classes. But found serious misunderstandings about comments in certain class sources:
What kind of abstraction CompatibilitySpace provides? Where & how should setNoLockWait(false) should be used? I found some class, called AccessManager or something like that. Searching didn't help to find out. So, what is the dedicated Derby Java class for that? I found this http://db.apache.org/derby/javadoc/engine/org/apache/derby/impl/store/access/btree/BTree.html, but conglomerate entity itself is a bit weird for me. Can someone help to understand that? I couldn't be aware of mentioning PersistentSet class ( http://db.apache.org/derby/javadoc/engine/org/apache/derby/iapi/services/property/PersistentSet.html). Any advice about farther investigations, in focus of general data binding strategies? http://db.apache.org/derby/javadoc/engine/org/apache/derby/impl/store/raw/xact/NoLocking.html, lockContainer(). Any suggestions about using it for general purposes? isIdle() is not static, thus means it wouldn't be referable, and should not be referable, because: 7.1. Either table does not support transaction - easy thing 7.2. Either table do support transactions, but their is no transactions for specific column (read: no transactions per table at mount of checking out/request processing time*, because locking is per only row or per table; both affect interested column) Not clear understood what is http://db.apache.org/derby/javadoc/engine/org/apache/derby/iapi/store/raw/Transaction.html#isPristine() method for... Transaction.anyoneBlocked(). Citation from javadocs: "Must only be called a previous local transaction was created and exists in the context. Can only be called if the current transaction is in the idle state." As already mentioned - unacceptable to check that from transaction class instance. Defin. out of context Purpose of TransactionFactory.noActiveUpdateTransaction() is unclear Curious about TransactionFactory.hasPreparedXact() is near... TransactionStatementNode.java: citation: "/** * A TransactionStatementNode represents any type of Transaction statement: * SET TRANSACTION, COMMIT, and ROLLBACK. * */" Not clearly understood: "SET TRANSACTION", or it is setting "TRANSACTION" mentioned. -1 for documentation team I haven't found any system tables for TransactionTable class. ?! Quiesce state - what is it? org.apache.impl.storeless.NoOpTransaction - not understood about purpose javax.sql.rowset.spi.TransactionalWriter BaseTableNumbersVisitor - what is that class for? org.apache.derby.impl.sql.compile.BaseColumnNode - ? org.apache.derby.impl.sql.compile.AccessPathImpl - ? org.apache.derby.impl.sql.compile.AllResultColumn - ? org.apache.derby.impl.sql.compile.BaseJoinStrategy - reflecting JOIN to SQL/XML would combine XML tags' attributes Not shure about how to translate ON statement equivalent to XPath queries, but if: 24.1. The architecture is NOT XML centric 24.2. The architecture (maybe) RDBMS centric (when customized virtual columns are populated from outer XML) there is a possibbility of using XML columns for refering tag attributes, so that would enlarge XML tree depth on binding, making possible to use XPath for traversing JOIN equivalent org.apache.derby.impl.sql.compile.ConditionalNode - must be constrained with XPath condition org.apache.derby.impl.sql.compile.ConstraintDefinitionNode - not fully clear org.apache.derby.impl.sql.compile.HalfOuterJoinNode - while translating XPath to SQL all RJOIN thing must be allready resolved, forming LJOIN SQL, instead leaving that for Derby core. That would make it more near to compiling SQL queries, relaxing database core loads; also it would enshure data consistency by avoiding hadling of cyclic table depency org.apache.derby.impl.sql.compile.IndexToBaseRowNode - not understood what this class is for org.apache.derby.impl.sql.compile.XMLTypeCompiler - good idea is to use views tables as backend for XML type A good idea to use *generated columns* feature of Derby to auto-generate custom columns from _external_ ONLY XML, not XML column type. Good for clients, who should have only SQL interface for Derby queries, and additional XML processing (read: after retrieving all data from result set) wouldn't be acceptable from client side org.apache.derby.diag.state.StatementCache - some explanation would be good here org.apache.derby.diag.LockTable - a rude way to find out whitch columns on whitch tables are locked. Or not? org.apache.derby.catalog.ReferencedColumns - ? org.apache.derby.iapi.store.access.AccessFactory - ? org.apache.derby.catalog.Dependable - ? org.apache.derby.catalog.DependableFinder - ? org.apache.derby.catalog.IndexDescriptor - ? org.apache.derby.impl.sql.execute.StatementTrigger - ? org.apache.derby.impl.sql.execute.TriggerInfo - ? org.apache.derby.impl.sql.execute.UnionResultSet - would be good if that could be used for mixing two XML results (SQL->XML) - ? org.apache.derby.impl.sql.depend.BasicDependency - ? org.apache.derby.impl.sql.depend.BasicDependencyManager - ? org.apache.derby.impl.sql.compile.XMLTypeCompiler - ? org.apache.derby.impl.sql.compile.XMLConstantNode - ? org.apache.derby.impl.sql.compile.SubqueryNode - could be translated to serve for XML results Besides concreate tree structure of subquery is less critical in terms of persistence; that is rather a responsibility of architecture, in which Derby involved, to enshure strict persistence in replication of post-request XML results of different SQl/XML clients Anyone, please help me with understanding all that stuff. John
