Re: opening multiple databases from same program

 Hi

Currently, all of my DB modification methods look like this:

    public void foobar() {
        SSessionJdbc session = ....;
        session.begin();
         ... do stuff here...
        session.commit();
        session.detachFromThread();  // <------ very very important!
    }

But yeah, I'm going to wrap SimpleORM in my own layer so I don't forget the last line, because it's a real pain tracking
down the problem when it occurs.

Thanks,
   Noel


[email protected] wrote:
>  
>
> 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]
> <mailto:berglas%40SpreadsheetDetective.com>>[email protected]
> <mailto:berglas%40SpreadsheetDetective.com> 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]
> <mailto:berglas%40spreadsheetdetective.com>>[email protected] <mailto:berglas%40spreadsheetdetective.com>
> >>>><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] <mailto:berglas%40spreadsheetdetective.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