Yes, that approach should work well.
Castor cannot determine (without adding lots of additional overhead) whether or not xsi:type will ever be needed until it encounters such a case. So it declares the xsi:type upon recognition of this. If you have many elements at the same level that require xsi:type then the xsi prefix will be declared on each element, unless it has been previously declared on a ancestor element. Setting the namespace mapping on the root will fix this issue. --Keith > Andrew Fawcett wrote: > > Heiko, > > > - The marshaller creates an xmlns:xsi attribute for each instance of > > > an object. If there are many objects that use the xsi:type > attribute, > > this increases the size of the xml file noticeable. > > Is there a way to force the marshaller to declare the xmlns:xsi > attribute > > only once? > > You could try using the addNamespaceMapping method on the Marshaller > to explicitly add the xsi namespace declaration before marshalling > your object. It should then get added at the root of your document and > not get repeated each time xsi:type is used. I've not tried this > myself but it's worth ago. ;-) > > Andy. > > -----Original Message----- > From: Heiko Erhardt [mailto:[EMAIL PROTECTED]] > Sent: 06 June 2002 11:36 > To: [EMAIL PROTECTED] > Subject: [castor-dev] xsi:type > > When marshalling objects to XML that are referenced in the mapping > file > as implemention of an interface instead of a concrete type, the > marshaller > creates a xsi:type specification like > > xsi:type="java:com.skynamics.prisma.core.process.EntryNodeImpl" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > Works fine, unmarshalling no problem. > However, some questions remain: > > - The marshaller creates an xmlns:xsi attribute for each instance of > an object. If there are many objects that use the xsi:type > attribute, > this increases the size of the xml file noticeable. > Is there a way to force the marshaller to declare the xmlns:xsi > attribute > only once? > > - The marshaller always refers to the Java type. It there a way to > refer > to the xml name spcecified in the <map-to xml="xxx"/> clauses of the > > mapping definition of the concrete object implementation? > > Hey - just found it in the code! If the marshaller considers the > class > to be introspected it will automatically use the Java name. > So - Is there a way to turn off introspection? (would be fine, due > to > performance reasons we're using mapping files with method specs > anyway...) > > TX, > > Heiko Erhardt > skynamics AG > www.skynamics.com > > > -----Original Message----- > > From: Richard Mottershead [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 11:53 AM > > To: [EMAIL PROTECTED] > > Subject: [castor-dev] Database Table Write Order > > > > > > Hi, I'm new to Castor, so appologies if I offend with my first set > of > > database related questions. > > > > Having downloaded and played with Castor for a while, it appears to > have > > facilities that allow developers to keep the time that database > locks are > > applied to a minimum. That said on large systems, to avoid deadlock, > it is > > important that All transactions access database tables (and rows > within each > > table) in the same order. If not then under conditions of heavy > load, > > deadlock can result. For example: Say transactions generally write > to tables > > in the order: > > 'aaa','bbb', 'ccc', 'ddd', 'eee', > > .. But one transaction writes to tables in the the order: > > order 'ddd', 'aaa', 'bbb', 'ccc'. > > These transactions will coexist perfectly well till a period of > particularly > > heavy load when a transaction of the first type and a transaction of > the > > second type hit a deadlock situation. i.e > > - The first transaction has a page lock on table 'aaa' which blocks > the > > second transaction. > > - The second transaction has a page lock on table 'ddd' which blocks > the > > first transaction. > > > > My questions follow on from this particular scenario, as follows: > > > > [1] Does the Castor database 'transaction completion' algorithm > read, write > > and lock all rows associated with the same database table at the > same time? > > (i.e. Is it possiblee for the algorithm to write data to table 'aaa' > then > > table 'bbb' and then table 'aaa' again. - If so then deadlock is > bound to > > occur in conditions of heavy usage at some point). > > > > [2] Can the order in which database tables are accessed at > 'transaction > > completion' time be specified in the Xml object to table mapping > file? If > > not is the order always the same (e.g. alphabetical). > > > > [3] Is it possible to prevent database views being specified instead > of > > database tables in the Xml object to table mapping file? I ask this > question > > because allowing the mapping of object data onto a view will alow > developers > > to break any 'table access order' rules crafted to prevent deadlock > (as the > > view could be of joined tables 'aaa' and 'zzz' and the same > transaction > > could then access table 'bbb' - which would break table ordering > rules > > described above). > > > > [4] Is it possible to apply database specific 'hints' to SQL queries > > > generated by the Castor data access layer. For example to run a > query so it > > will apply row locks and not escalate these to page locks. This is > often a > > method used by DBA's to prevent deadlock. > > > > Note: > > I could delve through the code and spend weeks looking for the above > > > information, but I'm asking those who know first. If you can answer > my > > questions and do know where the code is for the above algorithms, > can you > > point me in the correct direction. > > > > Thanx in advance, > > Richard Mottershead > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
