Re: SimpleORM Download Form

For master/slave replication I strongly suggest that you do that at 
the database level.  Oracle Data Guard, PostgreSQL does it 
(http://edoceo.com/liber/db-postgresql-replication), MS SQL, 
DB.2.  Not sure about MySQL.  It then becomes almost transparent to 
the application.

Anthony

At 12:09 AM 25/10/2008, you wrote:

>Anthony,
>
>Thanks for the pointers. Sorry I failed to mention that yes, this is 
>a master/slave setup - changes can only come from the master node. 
>The clustering is not for performance - purely for reliability. If 
>one node dies, the other nodes need to be up-to-date (and one will 
>take over as the master).
>
>I've been playing with the software a bit. It is looking good - as 
>long as I make sure that objects are only ever created using 
>SDataSet.createWithNullKey() (to avoid sequences being modified 
>outside commit()), I think its going to work great.
>
>
>Thanks,
>Carl Gould
>Inductive Automation
>[email protected]
>1.800.266.7798
>
>On Fri Oct 24 01:01:32 PDT 2008, Anthony & Melissa Berglas wrote:
>Hello Carl, You could just subtype SSessionJDBC and @Override 
>commit. However, you might be better working directly with the 
>methods in SDataSet. Realize that you can never keep multiple 
>databases in "Lock Step", unless they are master slave. Forget what 
>you read about two phase commit, it cannot be done. And why are you 
>doing it? If it is for reliability then you should use master/slave, 
>such as Oracle DataGuard. If it is for performance then the lock 
>stepping will slow you down more than just having one database. 
>Multiple database causes all sorts of problems (irrespective of 
>SimpleOrm). I strongly suggest that you try to implement a single 
>database solution. Mapping Students to Subjects (say) you just 
>explicitly create the Enrollment table. You will almost always want 
>that anyway to store Grades (say). Anthony At 03:28 AM 23/10/2008, 
>you wrote: >Anthony, > >Yes, I see what you're saying. 
>Getters/setters make working with >certain things (Wicket's 
>PropertyModels, for example) easier, but I >could always write my 
>own wicket models that would probably be more >powerful anyhow with 
>all of the extra meta-data that the SimpleORM >framework lets me 
>embed. > >I'm starting to think that my 2-week search for the right 
>ORM >framework might be over. Incidentally, you might be amused to 
>know >that my search started when I received my 840 (!!) page book 
>on >hibernate in the mail and then noticed the dozen or so extra 
>jar >files I needed just get get it to fire up... > >Perhaps you 
>could clear up one thing for me: > >Is it true that the following 
>would work? Our product uses JGroups >to cluster nodes to one 
>another. Each has its own copy of the >database, which are kept 
>synchronized in lockstep. Could I create a >facade around 
>SSessionJdbc that captured the call to "commit", and >actually 
>detached the DataSet, serialized it, broadcast it to all >nodes 
>(including the local node), and then re-attached it to a 
>new >transaction and committed it? > >Also, the whitepaper briefly 
>mentions having to create the mapping >entity for many-to-many 
>relationships. Are there any examples of >what this looks like 
>available? > >Thanks, >Carl Gould >Inductive 
>Automation >[email protected] >1.800.266.7798 > >On Tue 
>Oct 21 15:40:43 PDT 2008, Anthony Berglas wrote: >Hello Carl, There 
>is no actual need to write get/setters, and in >fact it is not often 
>done. Just myEmp.get(NAME) vs myEmp.getNAME(). >And for clustering 
>it becomes easy to write generic code like >myTable.get(myField). If 
>you do feel the need to write get/set >methods then the code 
>required is exactly the same as for beans and >pseudo POJOs. Without 
>get/setters then the static fields is much >*less* verbose than 
>annotations (and certainly XML). Non-db Uses do >not have to be 
>aware of the SSessionJDBC persistence module and jar. >They do have 
>to be vaguely aware of the SDataSet interface, but it >is about 
>collections of data rather than persistence. Anthony At >02:34 AM 
>22/10/2008, you wrote: >name: Carl Gould > >goodpart: 
>Tight >integration with how the data is stored >(accessibility to 
>IDs) can >help with web design (links need >IDs).Entities are 
>not >byte-enhanced or dynamic proxies - I need this >because I need 
>the >record instances to be serializable for >clustering.Clean 
>detachment >model will work well for me re: >clustering (I 
>think). > >concerns: >Having to define static field metadata as well 
>as >getters/setters >seems a bit more verbose that an 
>annotation-based >approach.Lack of >transparency means that all 
>developers need to >understand the >persistence 
>layer. > >organisation: Inductive 
>Automation > >city: >California > >orgdesc: Industrial automation 
>design software - >FactoryPMI > >nrprogrammers: 
>4 > >howknown: >http://java-source.net/open-source/persistence > >com 
>ments: Well >written documentation. It is only missing a list 
>of >supported >RDBMS, and a more in-depth discussion 
>about >schema >definition/change migration. Dr Anthony 
>Berglas, >[email protected] Mobile: +61 4 4838 8874 Just because 
>it is >possible to push twigs along the ground with ones nose does 
>not >necessarily mean that is the best way to collect firewood. 
>Spreadsheet Detective, Southern Cross Software Queensland Pty 
>Limited 54 Gerler Street Bardon, Queensland 4065, Australia. Email: 
>[email protected] www.SpreadsheetDetective.com Ph: 
>+61 427 830248 (Australian Eastern Standard Time) "If the model 
>seems correct only because the numbers look right, then why build 
>the model in the first place?"

Dr Anthony Berglas, [email protected]       Mobile: +61 4 4838 8874
Just because it is possible to push twigs along the ground with ones nose
does not necessarily mean that is the best way to collect firewood.


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/