Re: [SimpleORM] if(!session.hasBegun ()) begin() … if (!wasBegun) co mmit
John Abraham <[email protected]> Wed, 7 Mar 2012 15:18:42 -0700
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_FD47A470-C82D-4E2F-B954-65836D426B33
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
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 c=
onnected, keeps my one dataset of all the retrieved data (so that when the =
program ask for the same object again it gets it from the cache instead of =
making another copy from the database).
Are there any downsides to this technique that I've missed? If not, we sho=
uld add it as a SimpleORM method in SessionJdbc. We could call it "commitA=
ndStayConnected()" or "flushAndEndTransaction()" or whatever you want to c=
all 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 t=
hey have to choose between flushing (writing the data without ending the tr=
ansaction) and committing (writing the data and destroying all of their in-=
memory SRecordInstance objects).
--
John=20
On Mar 7, 2012, at 8:29 AM, John Abraham wrote:
> Thank you Franck for your ideas.
>=20
> 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 excep=
t some precondition checking and setting pointers. I also assumed reatta=
ching the SDataSet would start a new transaction in the database, but again=
, it seems to do nothing of the sort.
>=20=09
> I'm going to try doing a commitAndDetachDataSet() followed immediately by=
reattaching the dataset. This may release the transaction lock on the dat=
abase until the next query (the database would be IDLE instead of IDLE IN T=
RANSACTION). If I do this frequently enough it might work fine. I might e=
ven call this combination flushWithCommit().
>=20
> I use SSessionJdbc.getThreadLocalSession().find() in a lot of places in t=
he code to get objects by their primary key. If necessary I could replace =
all of these with a call to a utility routine somewhere that does
>=20
> 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 data=
base in 5 minutes or so commmitAndDetach the dataset again, only the commit=
AndDetach 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.
>=20
> This seems like a lot of work and complexity when all I want to do is wri=
te the changes to the database to free up the transaction processing on the=
database side.
>=20
>> Why do you want to keep the connection open ?
>=20
> If I have to write a utility routine to manage the detaching and attachin=
g, 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 w=
ith having connections open, as long as they aren't in a transaction. Look=
ing at my databases logs I see multiple connections from PGAdminIII and Qua=
ntum GIS lying open for days because people haven't closed the apps on thei=
r machines.
>=20
> --
> John=20
>=20
>=20
>=20
> On 2012-03-07, at 6:09 AM, Franck Routier wrote:
>=20
>> Hi,
>>=20
>> Le 06/03/2012 23:16, John Abraham a =E9crit :
>>>=20
>>>=20
>>> 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 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.
>>>=20
>>=20
>>> What's the best practice for begin.. commit wrapping like this?
>> Well, standard usage is like following :
>>=20
>> SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession();
>> try {
>> ses.begin();
>>=20
>> ... do you db work here
>>=20
>> ses.commit();
>> }
>> finally {
>> ses.close();
>> }
>>>=20
>>> I was thinking of wrapping a lot of my stuff in
>>>=20
>>> boolean wasBegun =3D true;
>>> if (!session.hasBegun()) {
>>> session.begin();
>>> wasBegun=3Dfalse;
>>> }
>>>=20
>>> =85 do my query and stuff=85.
>>>=20
>>> if (!wasBegun) session.commit();
>>>=20
>>>=20
>>> 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 occ=
urs randomly later on.
>>>=20
>>> What do you think of this plan? Is there a better system?
>> Do you need to handle one big transaction ? Simpleorm makes its best eff=
ort to assure things are coherent, using the optimistic lock approach. If o=
ne big transactin is not a real need for you, you should probably have some=
thing like :
>>=20
>> SDataSet staticDataDs =3D new SDataSet();
>> SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession();
>> try {
>> ses.begin(staticDataDs);
>> ... big initial queries here
>> ses.commitAndDetachDataSet();
>> }
>> finally {
>> ses.close();
>> }
>>=20
>> Then later on, when you happen to need to access the database,=20
>>=20
>> SSessionJdbc ses =3D SSessionJdbc.getThreadLocalSession();
>> try {
>> ses.begin();
>> ... other db work goes here
>> ses.commitAndDetachDataSet();
>> }
>> finally {
>> ses.close();
>> }
>>=20
>>=20
>> Does it make sense ?
>>=20
>> Regards,
>> Franck
>=20
--Apple-Mail=_FD47A470-C82D-4E2F-B954-65836D426B33
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></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
space; -webkit-line-break: after-white-space; ">
<div>It seems to work wonderfully to call this once in a while:</div><div><=
br></div><div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bott=
om: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span sty=
le=3D"color: #801a68">public</span> <span style=3D"color: #801a68">void</sp=
an> commitAndStayConnected() {</div><div style=3D"margin-top: 0px; margin-r=
ight: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal=
11px/normal Monaco; "><span class=3D"Apple-tab-span" style=3D"white-space:=
pre"> </span>SDataSet s =3D <span style=3D"color: #2a07c9">session</span>.=
commitAndDetachDataSet();</div><div style=3D"margin-top: 0px; margin-right:=
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px=
/normal Monaco; "><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
</span><span style=3D"color: #2a07c9">session</span>.begin(s);</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-lef=
t: 0px; font: normal normal normal 11px/normal Monaco; "><span class=3D"App=
le-tab-span" style=3D"white-space:pre"> </span>}</div></div><div><br></div>=
<div>This allows the database to release the transaction but leaves everyth=
ing connected, keeps my one dataset of all the retrieved data (so that when=
the program ask for the same object again it gets it from the cache instea=
d of making another copy from the database).</div><div><br></div><div>Are t=
here any downsides to this technique that I've missed? If not, we sho=
uld add it as a SimpleORM method in SessionJdbc. We could call it "co=
mmitAndStayConnected()" or "flushAndEndTransaction()" or whatever you=
want to call it. New users of SimpleORM would see that they can flus=
h 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 withou=
t ending the transaction) and committing (writing the data and destroying a=
ll of their in-memory SRecordInstance objects).</div><div><br></div><div>--=
</div><div>John </div><div><br></div><br><div><div>On Mar 7, 2012, at =
8:29 AM, John Abraham wrote:</div><br class=3D"Apple-interchange-newline"><=
blockquote type=3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space; "><div>Thank you Franck=
for your ideas.</div><div><br></div><div>I assumed there was a lot of over=
head in reattaching a dataset. I don't know why I assumed that, looki=
ng at the code it seems it does nothing except some precondition checking a=
nd setting pointers. I also assumed reattaching the SData=
Set would start a new transaction in the database, but again, it seems to d=
o nothing of the sort.</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span></div><div>I'm going to try doing a commitAndDetachD=
ataSet() followed immediately by reattaching the dataset. This may re=
lease the transaction lock on the database until the next query (the databa=
se would be IDLE instead of IDLE IN TRANSACTION). If I do this freque=
ntly enough it might work fine. I might even call this combination fl=
ushWithCommit().</div><div><br></div><div>I use SSessionJdbc.getThreadLocal=
Session().find() in a lot of places in the code to get objects by their pri=
mary key. If necessary I could replace all of these with a call to a =
utility routine somewhere that does</div><div><br></div><div><font class=3D=
"Apple-style-span" face=3D"Courier" style=3D"font-size: 11px;">object  =
;=3D mySDataSet.find()</font></div><div><font class=3D"Apple-style-span" fa=
ce=3D"Courier" style=3D"font-size: 11px;">if (object =3D=3D null) {</font><=
/div><div><font class=3D"Apple-style-span" face=3D"Courier" style=3D"font-s=
ize: 11px;"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </spa=
n>ses.attach(mySDataSet)</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier" style=3D"font-size: 11px;"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>ses.mustFind()</font></div><div><font cla=
ss=3D"Apple-style-span" face=3D"Courier" style=3D"font-size: 11px;">}</font=
></div><div><font class=3D"Apple-style-span" 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, onl=
y the commitAndDetach can't happen in a separate thread because SimpleORM i=
sn't thread safe so I'd have to poll a timer now and again in my main threa=
d.</font></div><div><br></div><div>This seems like a lot of work and comple=
xity 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><blockquote type=3D"cite"><div>Why do you want to keep the connection =
open ?<br></div></blockquote><div><br></div>If I have to write a utility ro=
utine to manage the detaching and attaching, it could also close the connec=
tion 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 log=
s I see multiple connections from PGAdminIII and Quantum GIS lying open for=
days because people haven't closed the apps on their machines.<br><div><br=
></div><div>--</div><div>John </div><div><br></div><div><br></div><br>=
<div><div>On 2012-03-07, at 6:09 AM, Franck Routier wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite">
=20=20
<meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Conte=
nt-Type">
=20=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi,<br>
<br>
Le 06/03/2012 23:16, John Abraham a =E9crit :
<blockquote cite=3D"mid:8FFD3646-0320-4AEB-98C2-4FA814B1CA6C@hbaspecto.=
com" type=3D"cite">
<span style=3D"display:none"> </span>
=20=20=20=20=20=20
<div id=3D"ygrp-text"><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. So 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>
</div>
</div>
</blockquote><br>
<blockquote cite=3D"mid:8FFD3646-0320-4AEB-98C2-4FA814B1CA6C@hbaspecto.=
com" type=3D"cite">
<div id=3D"ygrp-mlmsg" style=3D"position: relative;">
<div id=3D"ygrp-msg" style=3D"z-index: 1;">
<div id=3D"ygrp-text">
<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>
ses.begin();<br>
<br>
... do you db work here<br>
<br>
ses.commit();<br>
}<br>
finally {<br>
ses.close();<br>
}<br>
<blockquote cite=3D"mid:8FFD3646-0320-4AEB-98C2-4FA814B1CA6C@hbaspecto.=
com" type=3D"cite">
<div id=3D"ygrp-mlmsg" style=3D"position: relative;">
<div id=3D"ygrp-msg" style=3D"z-index: 1;">
<div id=3D"ygrp-text">
<div><br>
</div>
<div>I was thinking of wrapping a lot of my stuff in</div>
<div><br>
</div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'">bo=
olean
wasBegun =3D true;</font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'">if
(!session.hasBegun()) {</font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'">&n=
bsp;
session.begin();</font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'">&n=
bsp;
wasBegun=3Dfalse;</font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'">}<=
/font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'"><b=
r>
</font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'">=
=85
do my query and stuff=85.</font></div>
<div><font class=3D"Apple-style-span" face=3D"'Courier New'"><b=
r>
</font></div>
<div><font class=3D"Apple-style-span" 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? Is 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>
ses.begin(staticDataDs);<br>
... big initial queries here<br>
ses.commitAndDetachDataSet();<br>
}<br>
finally {<br>
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>
ses.begin();<br>
... other db work goes here<br>
ses.commitAndDetachDataSet();<br>
}<br>
finally {<br>
ses.close();<br>
}<br>
<br>
<br>
Does it make sense ?<br>
<br>
Regards,<br>
Franck<br>
</div>
</blockquote></div><br></div></blockquote></div><br>
<!-- |**|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=3D2048/stime=3D1331158729" width=3D"1" height=3D"1"> <=
br>
<!-- |**|end egp html banner|**| -->
=20=20=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=
JmcmlsNjZ2BF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlY=
wNmdHIEc2xrA3N0bmdzBHN0aW1lAzEzMzExNTg3Mjk-">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=
JkcTR1ZjZxBF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlY=
wNmdHIEc2xrA2hwZgRzdGltZQMxMzMxMTU4NzI5">
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>
--Apple-Mail=_FD47A470-C82D-4E2F-B954-65836D426B33--