I, too, would like to see Transactions be monadic.

--j

On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
<lgreg.mered...@gmail.com>wrote:

> Jonas,
>
> i applaud the effort. i agree with DPP sentiments regarding annotations.
> That said, i feel pretty comfortable that transactions fit entirely in a
> monadic context. Since LINQ demonstrates that query fits into monadic
> context, and there's already at least one Scala implementation of 
> LINQ<http://github.com/szeiger/scala-query/tree/master>,
> might i suggest that you come up with a monadic presentation first and then
> map the sugar to that. My guess is that the sugar will be informed by the
> monadic presentation.
>
> To be suggestive... think of a context with a Tx object, TxCtxt, as like an
> Option widget. Then you do stuff inside a transaction via
>
> for ( myTransactedWidget <- TxCtxt if <someCondition> ) yield {
> <someOperationsThatNeedToBeTransacted> }
>
> If you implement flatMap, yada, on TxCtxt you can have fun with nested
> transaction semantics. The point is that this should just work with a
> LINQ-like presentation of query.
>
> Best wishes,
>
> --greg
>
>
> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér <jbo...@gmail.com> wrote:
>
>>
>> I'll go for closures. Much simpler and less intrusive into Lift.
>> The current impl is based on Atomikos and Hibernate, I'll start with
>> pushing that in and we can make it pluggable later.
>> For example for Hibernate one need to add a line to the hibernate
>> config to register the
>> org.hibernate.transaction.TransactionManagerLookup class in order to
>> make Hibernate aware of our TX manager.
>>
>> Should I fork the github repo and submit patches or how do you guys work?
>>
>> /Jonas
>>
>>
>> 2009/5/29 Derek Chen-Becker <dchenbec...@gmail.com>:
>> > I'd vote for closures. We use annotations for JPA because we have to,
>> but
>> > IMHO closures provide a nicer semantic approach because they
>> syntactically
>> > enclose the block where the action is occurring.
>> >
>> > Derek
>> >
>> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér <jbo...@gmail.com> wrote:
>> >>
>> >> No perf difference. The annotations are turned into the same exact
>> >> closures.
>> >>
>> >> 2009/5/29 Timothy Perrett <timo...@getintheloop.eu>:
>> >> >
>> >> >
>> >> > Are there any performance implications considering closures vs
>> >> > annotations?
>> >> > Agreed that closures are more "lift like" however.
>> >> >
>> >> > Cheers, Tim
>> >> >
>> >> > On 29/05/2009 10:21, "marius d." <marius.dan...@gmail.com> wrote:
>> >> >
>> >> >>
>> >> >> I think that would be really good. But I'd rather not use
>> annotations.
>> >> >> Personally I find closures approach a much better fit here.
>> >> >>
>> >> >> withTxRequired {
>> >> >>   ... // do transational stuff
>> >> >>
>> >> >> }
>> >> >>
>> >> >>
>> >> >> Br's,
>> >> >> Marius
>> >> >>
>> >> >> On May 29, 11:55 am, Jonas Bonér <jbo...@gmail.com> wrote:
>> >> >>> Hi guys.
>> >> >>>
>> >> >>> I have been talking with David Pollak the rest of the lift team
>> about
>> >> >>> adding JTA to Lift. I have implemented that for a product written
>> in
>> >> >>> Scala some time ago. Now some of that code is OSS
>> >> >>> at:http://github.com/jboner/skalman/tree
>> >> >>>
>> >> >>> We used using two different APIs.
>> >> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> >> >>> grab them from a factory):
>> >> >>>
>> >> >>> @TransactionAttribute(REQUIRED)
>> >> >>> def transactionalMethod = { ... }
>> >> >>>
>> >> >>> 2. Call-by-name:
>> >> >>>
>> >> >>> withTxRequired {
>> >> >>>   ... // do transational stuff
>> >> >>>
>> >> >>> }
>> >> >>>
>> >> >>> But I don't know what fits Lift and would like to know how you guys
>> >> >>> would like to have JTA integrated.
>> >> >>> At which level? Which APIs? Etc.
>> >> >>>
>> >> >>> --
>> >> >>> Jonas Bonér
>> >> >>>
>> >> >>> twitter: @jboner
>> >> >>> blog:    http://jonasboner.com
>> >> >>> work:  http://crisp.se
>> >> >>> work:  http://scalablesolutions.se
>> >> >>> code:  http://github.com/jboner
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Jonas Bonér
>> >>
>> >> twitter: @jboner
>> >> blog:    http://jonasboner.com
>> >> work:   http://crisp.se
>> >> work:   http://scalablesolutions.se
>> >> code:   http://github.com/jboner
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> twitter: @jboner
>> blog:    http://jonasboner.com
>> work:   http://crisp.se
>> work:   http://scalablesolutions.se
>> code:   http://github.com/jboner
>>
>>
>>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to