Re: opening multiple databases from same program
[email protected] Sun, 03 Oct 2010 12:49:21 +1000
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <[email protected]> |
Hello Noel, No need to fork the code, the hooks you need are already there, although you might like to wrap them. (attach/detachFromThread). If you do end up using multiple threads, then query into a DataSet, detach the data set, and send it to the UI thread. In that way your threading will always be clean. But I agree, avoid threads. Anthony At 08:08 PM 23/09/2010, Noel Grandin wrote: > > > >That sounds like a good idea, and I tried in my last project. Turns out it's much harder than it seems. >Firstly, you need lots of extra boilerplate code. But I can live with that. > >More importantly, I have to be very very careful about disabling relevant pieces of the UI so I don't end up having 2 background queries stomping on each other. >It is really really easy to have the user click on 2 things in succession, the 2 queries both execute in the background, and then my applications state becomes horribly messed up. > >Basically, it's more pain than it's worth, especially since 99.9% of the time my queries execute fast enough that I don't need to execute them in the background. > >And I believe that libraries like SimpleORM should strive to make my life easier, not harder. >Especially when all I asking for is a way to disable some checking. > >After all, I am the programmer, should I not be in control of the situation, rather than having the library force me into one way of doing things? > >-- Noel. > >Thomas Leichner wrote: >> >>You can have a Swing desktop application and work with many threads. You can >>send the Swing event thread a command with the EventQueue.invokeLater >>function. You can also send a command from the Swing event thread to your own >>threads, implementing the same mechanism, which is used by the EventQueue >>class. This will be much easier than changing the SimpleORM source code. And >>it is much more flexible. For example, your swing application is still able to >>react, when a long drawn database sql-statement is executed. In the Java >>standard library you can find everything you need to implement such a solution. >> >> >>Thomas >> >> >> >>Am Dienstag, 21. September 2010, um 14:33:29 schrieben Sie: >>> >>>I'm effectively running several smaller apps inside the same Java VM. >>>Each app has it's own database. >>>Since this is a Swing desktop application, most of the action happens on >>>the Swing event dispatch thread. This means that I end up talking to >>>multiple databases from the same thread, triggering the check. >>> >>>Sigh. I keep having this problem. >>>Everybody is developing web-applications these days, which means that all >>>of the ORM frameworks are designed around the HTTP request-response cycle. >>>I ended up dumping Hibernate because it won't play nice with desktop >>>applications. >>> >>>Luckily SimpleORM is relatively straight-forward code, so I'm probably just >>>going to run my own private branch of it, since my changes don't seem to >>>meet with popular approval. >>> >>>-- Noel >>> >>><mailto:[email protected]>[email protected] wrote: >>>> >>>>It is actually possible to dissassociate sessions from threads, and thus >>>>have several. But that is a very odd thing to want to do. What are you >>>>trying to achieve? >>>> >>>>(Ususally trying to open a session on a thread that already has an open >>>>session means that you did not close the previous session, leading to a >>>>connection leak, which is why SimpleOrm fails fast.) >>>> >>>>Anthony >>>> >>>>At 02:02 AM 10/07/2010, you wrote: >>>>> >>>>>Hi, >>>>> >>>>>well, AFAIK, you can't do that... ! >>>>> >>>>>SSessionJdbc has built-in checks that a connection is single threaded >>>>>using a ThreadLocal object. [I think Hibernate has some kind of best >>>>>practice to achieve the same goal (I'm not formal here, I didn't use >>>>>hibernate for years)] >>>>> >>>>>There is only one dataSource per SSessionJdbc and one SSessionJdbc per >>>>>thread. >>>>> >>>>>You could implement a different strategy to handle this part. Some work >>>>>was done along this path in a previous version of Simpleorm, for using a >>>>>single JTA transaction per session. But it is not maintained. >>>>>See simpleorm/extras/SConnectionEJB.java >>>>> >>>>>My question would be : what are you trying to achieve ? >>>>> >>>>>Franck >>>>> >>>>>Le vendredi 09 juillet 2010 à 17:11 +0200, Noel Grandin a écrit : >>>>>> >>>>>>Hi >>>>>> >>>>>>I'm opening multiple different databases from the same thread, which >>>>>>is triggering this check: >>>>>> >>>>>>simpleorm.utils.SException$Error: Thread's SSession already open [SS >>>>>>1.SkyMon] >>>>>>[<mailto:0@17:08:40.976>0@17:08:40.976] !SE>: at >>>>>>simpleorm.sessionjdbc.SSessionJdbc.innerOpen(SSessionJdbc.java:129) >>>>>>[<mailto:0@17:08:40.976>0@17:08:40.976] !SE>: at >>>>>>simpleorm.sessionjdbc.SSessionJdbc.open(SSessionJdbc.java:88) >>>>>>[<mailto:0@17:08:40.976>0@17:08:40.976] !SE>: at >>>>>>simpleorm.sessionjdbc.SSessionJdbc.open(SSessionJdbc.java:108) >>>>>> >>>>>> >>>>>>What do I do? >>>>>> >>>>>>Thanks, Noel Grandin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>__________________________________________________________ >>>>>>Disclaimer: >>>>>><http://www.peralex.com/disclaimer.html>http://www.peralex.com/discla >>>>>>imer.html >>>> >>>> >>>>Spreadsheet Detective, >>>>Southern Cross Software Queensland Pty Limited >>>>54 Gerler Street >>>>Bardon, Queensland 4065, Australia. >>>> >>>>Email: <mailto:[email protected]>[email protected] >>>><mailto:berglas%40spreadsheetdetective.com> <http://www.SpreadsheetDetective.com>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?" >>> >>> >>>Disclaimer: <http://www.peralex.com/disclaimer.html>http://www.peralex.com/disclaimer.html >> >> >> >> >>------------------------------------ >> >>Yahoo! Groups Links >> >> >> >> > > > > >---------- >Disclaimer: <http://www.peralex.com/disclaimer.html>http://www.peralex.com/disclaimer.html > > 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?" ------------------------------------ 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: [email protected] [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/