commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject [Simper] adding a transaction API (was Re: Bean storage in database)
Date Sat, 02 Feb 2002 20:28:59 GMT
Bryan

Another thought on Simper. It'd be nice to add an explicit transaction API
to Simper, then when needed transactional units of database code could be
done using code similar to Juozas' example. This would allow Simper to work
outside of Servlets or on pre 2.3 Servlet engines - or allow more complex
transactional units to be done such as committing small units of work as you
go rather than doing it all in one batch at the end of a HTTP request.

e.g. some code might try to commit changes to the database, if they fail,
rollback then do something else (which might involve some other database
commits.

It doesn't have to be anything grand. Something simple like

simper.begin(); // (*)
SimperBean newAuthor = simper.create("authors");
// Set some properties
newAuthor.set("name", name);
newAuthor.set("email", email);
simper.commit();

The only issue to be careful of is threading, though it appears from the
Simpler code that everythings nicely ThreadLocal'd anyways so it should work
a treat.

Its essentially just moving the existing 'transaction' code into a
transaction API in the Simper class then moving the Servlet Filter to a new
class (SimperServletFilter) which would just call the transaction API. This
also removes the direct dependency of Simper on Servlet 2.3 as
SimperServletFilter becomes an optional utility class - developers could
always explicitly scope their transactions without needing Servlet Filters.

(*) the begin() method might well be redundant, commit() and rollback()
might just do it.

James
----- Original Message -----
From: "Juozas Baliuka" <baliuka@mwm.lt>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Saturday, February 02, 2002 5:50 PM
Subject: Re: Bean storage in database


> Hi,
> Yes simpler is good idea, I think abaut the same. Example in simplestore
> uses the same ideas.
> Implementation looks some diferent, but I think we can work together , I
> have the same ideas about transactions, "Value Objects" .... .
>
> Fragment from simpler usage :
> SimperBean newAuthor = simper.create("authors");
>    // Set some properties (this works the same whether creating new rows
or
> editing existing ones)
>    newAuthor.set("name", name);
>    newAuthor.set("email", email);
>    // Save a message for the JSP page, and show a JSP page
>
> Fragment from simplestore example test:
>
>             TestPersistence testObject;//only interface types supported at
> this time
>             Transaction t =  pm.getTransaction();
>             t.begin();
>             testObject =
> (TestPersistence)pm.createInstance(TestPersistence.class);
>             testObject.setBoolVal(true);
>             testObject.setIntVal(777);
>             assertEquals(testObject.getIntVal(),777);
>             testObject.setStrVal("TEST");
>             testObject.setDateVal(new java.util.Date());
>             testObject.setFloatVal(3f);
>             t.commit();
>
>
> ----- Original Message -----
> From: "Bryan Field-Elliot" <bryan_lists@netmeme.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Saturday, February 02, 2002 4:54 PM
> Subject: Re: Bean storage in database
>
>
>
>
> > Hi Juozas,
> >
> > Before starting your project this weekend, I recommend you have a look
> > at my Simper framework, which does roughly what you describe already.
> > I'm in the process of working with Ted Husted to get it submitted into
> > the sandbox here. In the meantime, take a look at:
> >
> > http://www.netmeme.org/simper
> >
> > Feature highlights include:
> > - Wrapping of table rows using the new DynaBean
> > - Automatic change detection and writing back to database, like EJB CMP
> > - Automatic use of Servlet 2.3 filters to demark transactions (also like
> > EJB entity beans)
> > - Support for relations between table, in a querying capacity (not
> > cascading updates or deletes)
> > - < 1,500 lines of code - simple to understand, yet packs a punch
> > - README describes rationale behind it's design and the tradeoffs made
> > (coming from an EJB CMP perspective)
> >
> > Thanks,
> >
> > Bryan
> >
> >
> > On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
> >
> >     Hi,
> >     this work will be started today. It will be simplestore samples.
> >     I will try to clear my code, it is very dirty and have a lot of bugs
> at
> >     this time.
> >     I decided to implement this for my current project, but I see it can
> be
> >     useful in some more common situations.
> >     I think it is more example for simplestore usage, not any kind of
> framework.
> >     It will be very limited, but it always possible to enhance. I will
use
> this
> >     for "readonly" data.
> >     like :
> >        CREATE VIEW  MY_STAT AS (  SELECT ID, SUM( SOMETHING ) ,
> >     COUNT(SOMETHING), MAX(SOMETHING)  FROM  MY_TABLE,
> >     ......     WHERE  ........   GROUP BY ID  HAVING ..... ORDER BY
> .    )
> >     I have plans to support "Stored  Procedures" , Transactions,
> >     Finders,  Relations .......... .
> >     But it is not very trivial to implement this stuff on this weekend
:)
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message