Re: [SimpleORM] if(!session.hasBegun()) begin() … if (!wasBegun) commit
anthony berglas <[email protected]> Mon, 16 Apr 2012 19:13:42 +1000
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <CA+_PZMdSdJpXhjhXM6Kvdr5zfgdXo8-dJdQbzrDNU+cueMYXNg@mail.gmail.com> |
--f46d043be02078817704bdc83f91 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello John, Your approach looks OK. But you understand that SimpleOrm is not a magic cache -- you cannot be notified about changes to the underlying database (using any ORM). The only thing that this does is warn you if you try to change records that have been changed elsewhere. If we reexamine the transaction structure we can consider this, but I suspect it is probably better put in your application to keep SimpleOrm conceptually simple. Thanks, Anthony On Thu, Mar 8, 2012 at 8:18 AM, John Abraham <[email protected]> wrote: > ** > > > It seems to work wonderfully to call this once in a while: > > public void commitAndStayConnected() { > SDataSet s =3D session.commitAndDetachDataSet(); > session.begin(s); > } > > This allows the database to release the transaction but leaves everything > connected, keeps my one dataset of all the retrieved data (so that when t= he > program ask for the same object again it gets it from the cache instead o= f > making another copy from the database). > > Are there any downsides to this technique that I've missed? If not, we > should add it as a SimpleORM method in SessionJdbc. We could call it > "commitAndStayConnected()" or "flushAndEndTransaction()" or whatever you > want to call it. New users of SimpleORM would see that they can flush > their data to the database and end the transaction, they won't be misled > into thinking they have to choose between flushing (writing the data > without ending the transaction) and committing (writing the data and > destroying all of their in-memory SRecordInstance objects). > > -- > John > > > On Mar 7, 2012, at 8:29 AM, John Abraham wrote: > > Thank you Franck for your ideas. > > I assumed there was a lot of overhead in reattaching a dataset. I don't > know why I assumed that, looking at the code it seems it does nothing > except some precondition checking and setting pointers. I also assumed > reattaching the SDataSet would start a new transaction in the database, b= ut > again, it seems to do nothing of the sort. > I'm going to try doing a commitAndDetachDataSet() followed immediately > by reattaching the dataset. This may release the transaction lock on the > database until the next query (the database would be IDLE instead of IDLE > IN TRANSACTION). If I do this frequently enough it might work fine. I > might even call this combination flushWithCommit(). > > I use SSessionJdbc.getThreadLocalSession().find() in a lot of places in > the code to get objects by their primary key. If necessary I could repla= ce > all of these with a call to a utility routine somewhere that does > > object =3D mySDataSet.find() > if (object =3D=3D null) { > ses.attach(mySDataSet) > ses.mustFind() > } > =85 set up some timing thing so that if there aren't any hits to the > database in 5 minutes or so commmitAndDetach the dataset again, only the > commitAndDetach can't happen in a separate thread because SimpleORM isn't > thread safe so I'd have to poll a timer now and again in my main thread. > > This seems like a lot of work and complexity when all I want to do is > write the changes to the database to free up the transaction processing o= n > the database side. > > Why do you want to keep the connection open ? > > > If I have to write a utility routine to manage the detaching and > attaching, it could also close the connection too after longer inactivity= , > and open a new one when the app needs it. But there doesn't seem to be a > problem with having connections open, as long as they aren't in a > transaction. Looking at my databases logs I see multiple connections fro= m > PGAdminIII and Quantum GIS lying open for days because people haven't > closed the apps on their machines. > > -- > John > > > > On 2012-03-07, at 6:09 AM, Franck Routier wrote: > > Hi, > > Le 06/03/2012 23:16, John Abraham a =E9crit : > > > > But some data does get changed, and there is always a chance that some > data might not get queried until much later in the simulation. So I thin= k > I need to keep a connection open, just commit it after the initial burst = of > queries, then <begin=85. commit> for any later queries that occur. > > > What's the best practice for begin.. commit wrapping like this? > > Well, standard usage is like following : > > SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession(); > try { > ses.begin(); > > ... do you db work here > > ses.commit(); > } > finally { > ses.close(); > } > > > I was thinking of wrapping a lot of my stuff in > > boolean wasBegun =3D true; > if (!session.hasBegun()) { > session.begin(); > wasBegun=3Dfalse; > } > > =85 do my query and stuff=85. > > if (!wasBegun) session.commit(); > > > This way I can use a big begin() commit() wrap for the all the initial > queries, then rely on smaller begin() commit() wraps for the stuff that > occurs randomly later on. > > What do you think of this plan? Is there a better system? > > Do you need to handle one big transaction ? Simpleorm makes its best > effort to assure things are coherent, using the optimistic lock approach. > If one big transactin is not a real need for you, you should probably hav= e > something like : > > SDataSet staticDataDs =3D new SDataSet(); > SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession(); > try { > ses.begin(staticDataDs); > ... big initial queries here > ses.commitAndDetachDataSet(); > } > finally { > ses.close(); > } > > Then later on, when you happen to need to access the database, > > SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession(); > try { > ses.begin(); > ... other db work goes here > ses.commitAndDetachDataSet(); > } > finally { > ses.close(); > } > > > Does it make sense ? > > Regards, > Franck > > >=20=20 > --=20 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 that is the best way to collect firewood. --f46d043be02078817704bdc83f91 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <head> <style type=3D"text/css"> <!-- /* start of attachment style */ .ygrp-photo-title{ clear: both; font-size: smaller; height: 15px; overflow: hidden; text-align: center; width: 75px; } div.ygrp-photo{ background-position: center; background-repeat: no-repeat; background-color: white; border: 1px solid black; height: 62px; width: 62px; } div.photo-title=20 a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited { text-decoration: none;=20 } div.attach-table div.attach-row { clear: both; } div.attach-table div.attach-row div { float: left; /* margin: 2px;*/ } p { clear: both; padding: 15px 0 3px 0; overflow: hidden; } div.ygrp-file { width: 30px; valign: middle; } div.attach-table div.attach-row div div a { text-decoration: none; } div.attach-table div.attach-row div div span { font-weight: normal; } div.ygrp-file-title { font-weight: bold; } /* end of attachment style */ --> </style> </head> <html> <head> <style type=3D"text/css"> <!-- #ygrp-mkp { border: 1px solid #d8d8d8; font-family: Arial; margin: 10px 0; padding: 0 10px; } #ygrp-mkp hr { border: 1px solid #d8d8d8; } #ygrp-mkp #hd { color: #628c2a; font-size: 85%; font-weight: 700; line-height: 122%; margin: 10px 0; } #ygrp-mkp #ads { margin-bottom: 10px; } #ygrp-mkp .ad { padding: 0 0; } #ygrp-mkp .ad p { margin: 0; } #ygrp-mkp .ad a { color: #0000ff; text-decoration: none; } --> </style> </head> <body> Hello John,<div><br></div><div>Your approach looks OK. =A0But you understan= d that SimpleOrm is not a magic cache -- you cannot be notified about chang= es to the underlying database (using any ORM). =A0The only thing that this = does is warn you if you try to change records that have been changed elsewh= ere.</div> <div><br></div><div>If we reexamine the transaction structure we can consid= er this, but I suspect it is probably better put in your application to kee= p SimpleOrm conceptually simple.</div><div><br></div><div>Thanks,</div> <div><br></div><div>Anthony<br><br><div class=3D"gmail_quote">On Thu, Mar 8= , 2012 at 8:18 AM, John Abraham <span dir=3D"ltr"><<a href=3D"mailto:jea= @hbaspecto.com">[email protected]</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> <u></u> <div style=3D"background-color:#fff"> <span>=A0</span> <div> <div> <div> =20=20=20=20=20=20 =20=20=20=20=20=20 <p></p><div>It seems to work wonderfully to call this once in a while= :</div><div><br></div><div><div><span style=3D"white-space:pre-wrap"> </spa= n><span style=3D"color:#801a68">public</span> <span style=3D"color:#801a68"= >void</span> commitAndStayConnected() {</div> <div><span style=3D"white-space:pre-wrap"> </span>SDataSet s =3D <span sty= le=3D"color:#2a07c9">session</span>.commitAndDetachDataSet();</div><div><sp= an style=3D"white-space:pre-wrap"> </span><span style=3D"color:#2a07c9">se= ssion</span>.begin(s);</div> <div><span style=3D"white-space:pre-wrap"> </span>}</div></div><div><br></d= iv><div>This allows the database to release the transaction but leaves ever= ything connected, keeps my one dataset of all the retrieved data (so that w= hen the program ask for the same object again it gets it from the cache ins= tead of making another copy from the database).</div> <div><br></div><div>Are there any downsides to this technique that I've= missed? =A0If not, we should add it as a SimpleORM method in SessionJdbc. = =A0We could call it "commitAndStayConnected()" =A0or "flushA= ndEndTransaction()" or whatever you want to call it. =A0New users of S= impleORM would see that they can flush their data to the database and end t= he transaction, they won't be misled into thinking they have to choose = between flushing (writing the data without ending the transaction) and comm= itting (writing the data and destroying all of their in-memory SRecordInsta= nce objects).</div> <div><br></div><div>--</div><div>John=A0</div><div><div></div><div class=3D= "h5"><div><br></div><br><div><div>On Mar 7, 2012, at 8:29 AM, John Abraham = wrote:</div><br><blockquote type=3D"cite"><div><div>Thank you Franck for yo= ur ideas.</div> <div><br></div><div>I assumed there was a lot of overhead in reattaching a = dataset. =A0I don't know why I assumed that, looking at the code it see= ms it does nothing except some precondition checking and setting pointers. = =A0=A0=A0I also assumed reattaching the SDataSet would start a new transact= ion in the database, but again, it seems to do nothing of the sort.</div> <div><span style=3D"white-space:pre-wrap"> </span></div><div>I'm going = to try doing a commitAndDetachDataSet() followed immediately by reattaching= the dataset. =A0This may release the transaction lock on the database unti= l the next query (the database would be IDLE instead of IDLE IN TRANSACTION= ). =A0If I do this frequently enough it might work fine. =A0I might even ca= ll this combination flushWithCommit().</div> <div><br></div><div>I use SSessionJdbc.getThreadLocalSession().find() in a = lot of places in the code to get objects by their primary key. =A0If necess= ary I could replace all of these with a call to a utility routine somewhere= that does</div> <div><br></div><div><font face=3D"Courier" style=3D"font-size:11px">object = =A0=3D mySDataSet.find()</font></div><div><font face=3D"Courier" style=3D"f= ont-size:11px">if (object =3D=3D null) {</font></div><div><font face=3D"Cou= rier" style=3D"font-size:11px"><span style=3D"white-space:pre-wrap"> </span= >ses.attach(mySDataSet)</font></div> <div><font face=3D"Courier" style=3D"font-size:11px"><span style=3D"white-s= pace:pre-wrap"> </span>ses.mustFind()</font></div><div><font face=3D"Courie= r" style=3D"font-size:11px">}</font></div><div><font face=3D"Courier" style= =3D"font-size:11px">=85 set up some timing thing so that if there aren'= t any hits to the database in 5 minutes or so commmitAndDetach the dataset = again, only the commitAndDetach can't happen in a separate thread becau= se SimpleORM isn't thread safe so I'd have to poll a timer now and = again in my main thread.</font></div> <div><br></div><div>This seems like a lot of work and complexity when all I= want to do is write the changes to the database to free up the transaction= processing on the database side.</div><div><br></div><div></div><blockquot= e type=3D"cite"> <div>Why do you want to keep the connection open ?<br></div></blockquote><d= iv><br></div>If I have to write a utility routine to manage the detaching a= nd attaching, it could also close the connection too after longer inactivit= y, and open a new one when the app needs it. =A0But there doesn't seem = to be a problem with having connections open, as long as they aren't in= a transaction. =A0Looking at my databases logs I see multiple connections = from PGAdminIII and Quantum GIS lying open for days because people haven= 9;t closed the apps on their machines.<br> <div><br></div><div>--</div><div>John=A0</div><div><br></div><div><br></div= ><br><div><div>On 2012-03-07, at 6:09 AM, Franck Routier wrote:</div><br><b= lockquote type=3D"cite"> =20=20 =20=20=20=20 =20=20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Hi,<br> <br> Le 06/03/2012 23:16, John Abraham a =E9crit=A0: <blockquote type=3D"cite"> <span>=A0</span> =20=20=20=20=20=20 <div><br> <div>But some data does get changed, and there is always a chance that some data might not get queried until much later in the simulation. =A0So I think I need to keep a connection open, just commit it after the initial burst of queries, then <begin=85. commit> for any later queries that occur.</div> <div><br> </div> </div> </blockquote></div> </blockquote></div> </div></blockquote><br> <blockquote type=3D"cite"> <div> <div> <div> <div>What's the best practice for begin.. commit wrapping like this?</div> </div> </div> </div> </blockquote> Well, standard usage is like following :<br> <br> SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession();<br> try {<br> =A0=A0=A0 ses.begin();<br> <br> ... do you db work here<br> <br> =A0=A0=A0 ses.commit();<br> }<br> finally {<br> =A0=A0=A0 ses.close();<br> }<br> <blockquote type=3D"cite"> <div> <div> <div> <div><br> </div> <div>I was thinking of wrapping a lot of my stuff in</div> <div><br> </div> <div><font face=3D"'Courier New'">boolean wasBegun =3D true;</font></div> <div><font face=3D"'Courier New'">if (!session.hasBegun()) {</font></div> <div><font face=3D"'Courier New'">=A0 =A0session.begin();</font></div> <div><font face=3D"'Courier New'">=A0 =A0wasBegun=3Dfalse;</font></div> <div><font face=3D"'Courier New'">}</font></div> <div><font face=3D"'Courier New'"><br> </font></div> <div><font face=3D"'Courier New'">=85 do my query and stuff=85.</font></div> <div><font face=3D"'Courier New'"><br> </font></div> <div><font face=3D"'Courier New'">if (!wasBegun) session.commit();</font></div> <div><br> </div> <div><br> </div> <div>This way I can use a big begin() commit() wrap for the all the initial queries, then rely on smaller begin() commit() wraps for the stuff that occurs randomly later on.</div> <div><br> </div> <div>What do you think of this plan? =A0Is there a better system?</div> </div> </div> </div> </blockquote> Do you need to handle one big transaction ? Simpleorm makes its best effort to assure things are coherent, using the optimistic lock approach. If one big transactin is not a real need for you, you should probably have something like :<br> <br> SDataSet staticDataDs =3D new SDataSet();<br> SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession();<br> try {<br> =A0=A0=A0 ses.begin(staticDataDs);<br> =A0=A0=A0 ... big initial queries here<br> =A0=A0=A0 ses.commitAndDetachDataSet();<br> }<br> finally {<br> =A0=A0=A0 ses.close();<br> }<br> <br> Then later on, when you happen to need to access the database, <br> <br> SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession();<br> try {<br> =A0=A0=A0 ses.begin();<br> =A0=A0=A0 ... other db work goes here<br> =A0=A0=A0 ses.commitAndDetachDataSet();<br> }<br> finally {<br> =A0=A0=A0 ses.close();<br> }<br> <br> <br> Does it make sense ?<br> <br> Regards,<br> Franck<br> </div> <br><br></div></div><p></p> </div> =20=20=20=20=20 =20=20=20=20 <div style=3D"color:#fff;min-height:0"></div> </div> =20=20 </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><p> </p><p>Dr Anthony Berglas, <a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>=A0=A0=A0=A0=A0=A0 Mobile: +61 4 4838 8874<= br> Just because it is possible to push twigs along the ground with ones nose<b= r> does not necessarily mean that that is the best way to collect firewood.</p= ><br> </div> <!-- |**|begin egp html banner|**| --> <br> =20=20=20=20 =20=20=20=20 <br> <!-- |**|end egp html banner|**| --> <div width=3D"1" style=3D"color: white; clear: both;"/>__._,_.___</div> <!-- Start Recommendations --> <!-- End Recommendations --> <!-- |**|begin egp html banner|**| --> <img src=3D"http://geo.yahoo.com/serv?s=3D97476590/grpId=3D7360226/grpspI= d=3D1705006905/msgId=3D2049/stime=3D1334567666" width=3D"1" height=3D"1"> <= br> <!-- |**|end egp html banner|**| --> =20=20 <!-- |**|begin egp html banner|**| --> <br> <div style=3D"font-family: verdana; font-size: 77%; border-top: 1px s= olid #666; padding: 5px 0;" > Your email settings: Individual Email|Traditional <br> <a href=3D"http://groups.yahoo.com/group/SimpleORM/join;_ylc=3DX3oDMT= JmZzU5cWZiBF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlY= wNmdHIEc2xrA3N0bmdzBHN0aW1lAzEzMzQ1Njc2NjY-">Change settings via the Web</a= > (Yahoo! ID required) <br> Change settings via email: <a href=3D"mailto:SimpleORM-digest@yahoogr= oups.com?subject=3DEmail Delivery: Digest">Switch delivery to Daily Digest<= /a> | <a href =3D "mailto:[email protected]?subject=3D= Change Delivery Format: Fully Featured">Switch to Fully Featured</a> <br> <a href=3D"http://groups.yahoo.com/group/SimpleORM;_ylc=3DX3oDMT= JkN3JkMXYxBF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlY= wNmdHIEc2xrA2hwZgRzdGltZQMxMzM0NTY3NjY2"> Visit Your Group=20 </a> | <a href=3D"http://docs.yahoo.com/info/terms/"> Yahoo! Groups Terms of Use </a> | <a href=3D"mailto:[email protected]?subject=3DUns= ubscribe"> Unsubscribe=20 </a>=20 <br> </div> <br> <!-- |**|end egp html banner|**| --> <div style=3D"color: white; clear: both;"/>__,_._,___</div> </body> </html> --f46d043be02078817704bdc83f91--