On Fri, May 29, 2009 at 7:19 PM, Josh Suereth <joshua.suer...@gmail.com>wrote:

> +30000000000000


See http://github.com/dpp/goatrodeo/tree/master

>
>
> So many pluses in fact, that we are already experimenting with this concept
> at work.  Unfortunately, the source may not be "openable".  I'd be more than
> willing to contribute to an open-source JTA monadic library.
>
> for( tx <- context) {
>    //Do stuff....
>    if(somethingBad) tx.rollback()
>    //Do more stuff
> }
>
> Just seems to fit the needs of my software *much* better than the magical
> annotated method...errr... method seen in EJB and Spring.
>
>
> -Josh
>
>
> On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz <jorge.or...@gmail.com>wrote:
>
>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~---------~--~----~------------~-------~--~----~
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